"id","task_title","comment_text","date_created","AuthorPHID","TaskPHID","comment_type","text_for_analysis","cleaned_messages","priority","priority_score","date_closed","CloserPHID","status","time_flag","source","phase","author_closer","same_author","week_index","http_flag","olmo_cleaned_sentences","resolution_outcome","verification_sample","cleaned_sentences" 488,"VisualEditor: HTML comments are dropped from transclusion calls","https://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655",1371265140,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-b7q472kz3l2dnhbtziiw","task_description","VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL URL","Unbreak Now!",100,1371511467,NA,"resolved","True","c1",2,"True","False",-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', 'URL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links.', 'However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"".', 'These comments often have important messages to other editors, so they can not be stripped.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,"VisualEditor: HTML comments are dropped from transclusion calls." 488,"VisualEditor: HTML comments are dropped from transclusion calls","https://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655",1371265140,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-b7q472kz3l2dnhbtziiw","task_description","VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL URL","Unbreak Now!",100,1371511467,NA,"resolved","True","c1",2,"True","False",-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', 'URL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links.', 'However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"".', 'These comments often have important messages to other editors, so they can not be stripped.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,"URL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links." 488,"VisualEditor: HTML comments are dropped from transclusion calls","https://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655",1371265140,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-b7q472kz3l2dnhbtziiw","task_description","VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL URL","Unbreak Now!",100,1371511467,NA,"resolved","True","c1",2,"True","False",-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', 'URL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links.', 'However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"".', 'These comments often have important messages to other editors, so they can not be stripped.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,"However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none""." 488,"VisualEditor: HTML comments are dropped from transclusion calls","https://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655",1371265140,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-b7q472kz3l2dnhbtziiw","task_description","VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL URL","Unbreak Now!",100,1371511467,NA,"resolved","True","c1",2,"True","False",-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', 'URL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links.', 'However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"".', 'These comments often have important messages to other editors, so they can not be stripped.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,"These comments often have important messages to other editors, so they can not be stripped." 488,"VisualEditor: HTML comments are dropped from transclusion calls","https://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655",1371265140,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-b7q472kz3l2dnhbtziiw","task_description","VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49603 https://bugzilla.wikimedia.org/show_bug.cgi?id=49655","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links. However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL URL","Unbreak Now!",100,1371511467,NA,"resolved","True","c1",2,"True","False",-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', 'URL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links.', 'However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per URL and ""the position of the pushpin label: left, right, top, bottom, none"".', 'These comments often have important messages to other editors, so they can not be stripped.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL" 489,"VisualEditor: HTML comments are dropped from transclusion calls","verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.",1417635932,"PHID-USER-4alekd35in5tg53zpsl4","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.","verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"['verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.']",NA,0,"verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions." 490,"VisualEditor: HTML comments are dropped from transclusion calls","verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.",1417635694,"PHID-USER-4alekd35in5tg53zpsl4","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.","verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"['verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.']",NA,0,"verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions." 491,"VisualEditor: HTML comments are dropped from transclusion calls","That's a separate bug, will raise as such.",1372002624,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","That's a separate bug, will raise as such.","That's a separate bug, will raise as such.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"[""That's a separate bug, will raise as such.""]",NA,0,"That's a separate bug, will raise as such." 492,"VisualEditor: HTML comments are dropped from transclusion calls","Not sure if it's the same thing, but I just did this today http://it.wikipedia.org/w/index.php?title=Google&diff=59622535&oldid=59377529 and it discarded commented text which, as noted above, should be there for a reason :)",1371996558,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","Not sure if it's the same thing, but I just did this today http://it.wikipedia.org/w/index.php?title=Google&diff=59622535&oldid=59377529 and it discarded commented text which, as noted above, should be there for a reason :)","Not sure if it's the same thing, but I just did this today URL and it discarded commented text which, as noted above, should be there for a reason :)",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-2,NA,"[""Not sure if it's the same thing, but I just did this today URL and it discarded commented text which, as noted above, should be there for a reason :)""]",NA,0,"Not sure if it's the same thing, but I just did this today URL and it discarded commented text which, as noted above, should be there for a reason :)" 493,"VisualEditor: HTML comments are dropped from transclusion calls","This is now fixed; as an example, see https://en.wikipedia.org/w/index.php?title=Bleak_House&diff=560362551&oldid=560338958 as an edit made with VisualEditor that leaves the comments in the templates as they were.",1371511467,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","This is now fixed; as an example, see https://en.wikipedia.org/w/index.php?title=Bleak_House&diff=560362551&oldid=560338958 as an edit made with VisualEditor that leaves the comments in the templates as they were.","This is now fixed; as an example, see URL as an edit made with VisualEditor that leaves the comments in the templates as they were.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['This is now fixed; as an example, see URL as an edit made with VisualEditor that leaves the comments in the templates as they were.']",NA,0,"This is now fixed; as an example, see URL as an edit made with VisualEditor that leaves the comments in the templates as they were." 494,"VisualEditor: HTML comments are dropped from transclusion calls","Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.",1371465156,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.","Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"[""Can't reproduce in master."", 'The comment appears in the template dialog and can be edited.', 'With experimental code disabled the template is completely untouched.']",NA,0,"The comment appears in the template dialog and can be edited." 494,"VisualEditor: HTML comments are dropped from transclusion calls","Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.",1371465156,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.","Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"[""Can't reproduce in master."", 'The comment appears in the template dialog and can be edited.', 'With experimental code disabled the template is completely untouched.']",NA,0,"With experimental code disabled the template is completely untouched." 494,"VisualEditor: HTML comments are dropped from transclusion calls","Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.",1371465156,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.","Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"[""Can't reproduce in master."", 'The comment appears in the template dialog and can be edited.', 'With experimental code disabled the template is completely untouched.']",NA,0,"Can't reproduce in master." 495,"VisualEditor: HTML comments are dropped from transclusion calls","(In reply to comment #3) > See also bug 49655 and this (where Ssastry discusses it): > Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox The place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there. :-) Bug 42124 is not relevant.",1371425926,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","(In reply to comment #3) > See also bug 49655 and this (where Ssastry discusses it): > Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox The place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there. :-) Bug 42124 is not relevant.","(In reply to comment #3) QUOTE QUOTE The place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there. :-) Bug 42124 is not relevant.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-3,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nThe place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there.', ':-) Bug 42124 is not relevant.']",NA,0,"(In reply to comment #3)\nQUOTE\nQUOTE\n\nThe place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there." 495,"VisualEditor: HTML comments are dropped from transclusion calls","(In reply to comment #3) > See also bug 49655 and this (where Ssastry discusses it): > Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox The place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there. :-) Bug 42124 is not relevant.",1371425926,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","(In reply to comment #3) > See also bug 49655 and this (where Ssastry discusses it): > Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox The place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there. :-) Bug 42124 is not relevant.","(In reply to comment #3) QUOTE QUOTE The place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there. :-) Bug 42124 is not relevant.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-3,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nThe place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there.', ':-) Bug 42124 is not relevant.']",NA,0,":-) Bug 42124 is not relevant." 496,"VisualEditor: HTML comments are dropped from transclusion calls","[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]] See also bug 42124.",1371424680,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]] See also bug 42124.","[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]] See also bug 42124.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]]\n\nSee also bug 42124.']",NA,0,"[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]]\n\nSee also bug 42124." 497,"VisualEditor: HTML comments are dropped from transclusion calls","See also bug 49655 and this (where Ssastry discusses it): Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox",1371424467,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","See also bug 49655 and this (where Ssastry discusses it): Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox","See also bug 49655 and this (where Ssastry discusses it): Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['See also bug 49655 and this (where Ssastry discusses it): \nWikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox']",NA,0,"See also bug 49655 and this (where Ssastry discusses it): \nWikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox" 498,"VisualEditor: HTML comments are dropped from transclusion calls","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",1371420455,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-3,NA,"[""Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?)."", 'Ed, can you confirm at your end if this is a DM issue or a Parsoid one?', 'I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?).', ""Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?)"", 'merged with the following transclusion.']",NA,0,"Ed, can you confirm at your end if this is a DM issue or a Parsoid one?" 498,"VisualEditor: HTML comments are dropped from transclusion calls","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",1371420455,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-3,NA,"[""Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?)."", 'Ed, can you confirm at your end if this is a DM issue or a Parsoid one?', 'I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?).', ""Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?)"", 'merged with the following transclusion.']",NA,0,"I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?)." 498,"VisualEditor: HTML comments are dropped from transclusion calls","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",1371420455,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-3,NA,"[""Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?)."", 'Ed, can you confirm at your end if this is a DM issue or a Parsoid one?', 'I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?).', ""Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?)"", 'merged with the following transclusion.']",NA,0,"merged with the following transclusion." 498,"VisualEditor: HTML comments are dropped from transclusion calls","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",1371420455,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-3,NA,"[""Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?)."", 'Ed, can you confirm at your end if this is a DM issue or a Parsoid one?', 'I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?).', ""Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?)"", 'merged with the following transclusion.']",NA,0,"Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?)." 498,"VisualEditor: HTML comments are dropped from transclusion calls","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",1371420455,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.","Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-3,NA,"[""Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?)."", 'Ed, can you confirm at your end if this is a DM issue or a Parsoid one?', 'I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?).', ""Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?)"", 'merged with the following transclusion.']",NA,0,"Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?)" 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"Page notices and edit notices are for a whole page or section." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"VE should not be doing anything within templates." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"Templates are too complex for VE to meddle with in the slightest way." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"VE should not even remove spaces in templates." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"But why bother?" 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?" 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"So one can read the hidden note in the popup." 499,"VisualEditor: HTML comments are dropped from transclusion calls","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",1371269621,"PHID-USER-ebwxbdwkoxprr4cvvjvy","PHID-TASK-b7q472kz3l2dnhbtziiw","task_subcomment","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.","At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.', 'Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.', 'Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc..', 'Page notices and edit notices are for a whole page or section.', 'For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.', 'If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.', 'They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.', 'VE should not be doing anything within templates.', 'Templates are too complex for VE to meddle with in the slightest way.', 'VE should not even remove spaces in templates.', 'If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool.', 'But why bother?', 'Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode?', 'So one can read the hidden note in the popup.', 'Kind of like how reference tooltips work.']",NA,0,"Kind of like how reference tooltips work." 524,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: https://cs.wikipedia.org/w/index.php?title=Manolo_Blahnik&oldid=10415532 -------------------------- **Version**: unspecified **Severity**: critical",1371213300,"PHID-USER-vm462i2ffbawnuo4mh3n","PHID-TASK-m3novk5xasw5lqvg62ye","task_description","New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: https://cs.wikipedia.org/w/index.php?title=Manolo_Blahnik&oldid=10415532 -------------------------- **Version**: unspecified **Severity**: critical","New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: URL -------------------------- **Version**: unspecified **Severity**: critical","Unbreak Now!",100,1371235366,NA,"resolved","True","c1",2,"False","False",-3,NA,"['New deployment of Parsoid leads to HTML insertion - needs deployed code reversion.', 'I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page.', 'See this revision: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion." 524,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: https://cs.wikipedia.org/w/index.php?title=Manolo_Blahnik&oldid=10415532 -------------------------- **Version**: unspecified **Severity**: critical",1371213300,"PHID-USER-vm462i2ffbawnuo4mh3n","PHID-TASK-m3novk5xasw5lqvg62ye","task_description","New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: https://cs.wikipedia.org/w/index.php?title=Manolo_Blahnik&oldid=10415532 -------------------------- **Version**: unspecified **Severity**: critical","New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: URL -------------------------- **Version**: unspecified **Severity**: critical","Unbreak Now!",100,1371235366,NA,"resolved","True","c1",2,"False","False",-3,NA,"['New deployment of Parsoid leads to HTML insertion - needs deployed code reversion.', 'I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page.', 'See this revision: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page." 524,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: https://cs.wikipedia.org/w/index.php?title=Manolo_Blahnik&oldid=10415532 -------------------------- **Version**: unspecified **Severity**: critical",1371213300,"PHID-USER-vm462i2ffbawnuo4mh3n","PHID-TASK-m3novk5xasw5lqvg62ye","task_description","New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: https://cs.wikipedia.org/w/index.php?title=Manolo_Blahnik&oldid=10415532 -------------------------- **Version**: unspecified **Severity**: critical","New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: URL -------------------------- **Version**: unspecified **Severity**: critical","Unbreak Now!",100,1371235366,NA,"resolved","True","c1",2,"False","False",-3,NA,"['New deployment of Parsoid leads to HTML insertion - needs deployed code reversion.', 'I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page.', 'See this revision: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"See this revision: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: critical" 525,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","*** Bug 50049 has been marked as a duplicate of this bug. ***",1372004983,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","*** Bug 50049 has been marked as a duplicate of this bug. ***","*** Bug 50049 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['*** Bug 50049 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50049 has been marked as a duplicate of this bug." 525,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","*** Bug 50049 has been marked as a duplicate of this bug. ***",1372004983,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","*** Bug 50049 has been marked as a duplicate of this bug. ***","*** Bug 50049 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['*** Bug 50049 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 526,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Yes, . It is apparently fixed.",1371657346,"PHID-USER-vyidforzdhnrsoweujao","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Yes, . It is apparently fixed.","Yes, . Should I open a new bug?",1371482523,"PHID-USER-vyidforzdhnrsoweujao","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","It has the VisualEditor tag and was reported in the feedback page . Should I open a new bug?","It has the VisualEditor tag and was reported in the feedback page , but that edit was made today.",1371477080,"PHID-USER-vyidforzdhnrsoweujao","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Not sure if this is related: , but that edit was made today.","Not sure if this is related: Issue started ~ 11:37 UTC today per > https://en.wikipedia.org/w/index. > php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges If that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it): Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-frontend]/Exec[load-new-vcl-file-frontend]) Triggered 'refresh' from 2 events ... Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-backend]/Exec[load-new-vcl-file]) Triggered 'refresh' from 2 events",1371219908,"PHID-USER-jtxavgb3caz53o45csni","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","(In reply to comment #3) > Issue started ~ 11:37 UTC today per > https://en.wikipedia.org/w/index. > php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges If that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it): Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-frontend]/Exec[load-new-vcl-file-frontend]) Triggered 'refresh' from 2 events ... Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-backend]/Exec[load-new-vcl-file]) Triggered 'refresh' from 2 events","(In reply to comment #3) QUOTE QUOTE QUOTE If that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it): Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-frontend]/Exec[load-new-vcl-file-frontend]) Triggered 'refresh' from 2 events ... Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-backend]/Exec[load-new-vcl-file]) Triggered 'refresh' from 2 events",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"[""(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nIf that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it):\n\nJun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-frontend]/Exec[load-new-vcl-file-frontend]) Triggered 'refresh' from 2 events\n...\nJun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-backend]/Exec[load-new-vcl-file]) Triggered 'refresh' from 2 events""]",NA,0,"(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nIf that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it):\n\nJun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-frontend]/Exec[load-new-vcl-file-frontend]) Triggered 'refresh' from 2 events\n...\nJun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-backend]/Exec[load-new-vcl-file]) Triggered 'refresh' from 2 events" 540,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236",1371219726,"PHID-USER-3qvsqam4jxugqg2l7qpw","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, URL",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['Yes, first time I tried the new VisualEditor.', 'My user page is live and I still left the HTML as an example.', 'Tried a few more times to blank page with VE, it is real ugly.', 'HTML leaks on HTML leaks on HTML leaks with each new save, URL']",NA,0,"Yes, first time I tried the new VisualEditor." 540,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236",1371219726,"PHID-USER-3qvsqam4jxugqg2l7qpw","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, URL",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['Yes, first time I tried the new VisualEditor.', 'My user page is live and I still left the HTML as an example.', 'Tried a few more times to blank page with VE, it is real ugly.', 'HTML leaks on HTML leaks on HTML leaks with each new save, URL']",NA,0,"My user page is live and I still left the HTML as an example." 540,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236",1371219726,"PHID-USER-3qvsqam4jxugqg2l7qpw","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, URL",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['Yes, first time I tried the new VisualEditor.', 'My user page is live and I still left the HTML as an example.', 'Tried a few more times to blank page with VE, it is real ugly.', 'HTML leaks on HTML leaks on HTML leaks with each new save, URL']",NA,0,"Tried a few more times to blank page with VE, it is real ugly." 540,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236",1371219726,"PHID-USER-3qvsqam4jxugqg2l7qpw","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236","Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, URL",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['Yes, first time I tried the new VisualEditor.', 'My user page is live and I still left the HTML as an example.', 'Tried a few more times to blank page with VE, it is real ugly.', 'HTML leaks on HTML leaks on HTML leaks with each new save, URL']",NA,0,"HTML leaks on HTML leaks on HTML leaks with each new save, URL" 541,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","This is occurring fairly widely and I have a lot of reports. Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).",1371217642,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","This is occurring fairly widely and I have a lot of reports. Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).","This is occurring fairly widely and I have a lot of reports. Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['This is occurring fairly widely and I have a lot of reports.', 'Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).']",NA,0,"This is occurring fairly widely and I have a lot of reports." 541,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","This is occurring fairly widely and I have a lot of reports. Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).",1371217642,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","This is occurring fairly widely and I have a lot of reports. Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).","This is occurring fairly widely and I have a lot of reports. Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['This is occurring fairly widely and I have a lot of reports.', 'Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).']",NA,0,"Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed)." 542,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Issue started ~ 11:37 UTC today per https://en.wikipedia.org/w/index.php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges",1371215939,"PHID-USER-3uecblbxq24ycewm2cog","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Issue started ~ 11:37 UTC today per https://en.wikipedia.org/w/index.php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges","Issue started ~ 11:37 UTC today per URL",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['Issue started ~ 11:37 UTC today per URL']",NA,0,"Issue started ~ 11:37 UTC today per URL" 543,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","More of this: https://de.wikipedia.org/w/index.php?title=Oper_K%C3%B6ln&curid=2386780&diff=119548868&oldid=118354900 https://test.wikipedia.org/w/index.php?title=User:Raymond/image&diff=174443&oldid=174442",1371214660,"PHID-USER-3uecblbxq24ycewm2cog","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","More of this: https://de.wikipedia.org/w/index.php?title=Oper_K%C3%B6ln&curid=2386780&diff=119548868&oldid=118354900 https://test.wikipedia.org/w/index.php?title=User:Raymond/image&diff=174443&oldid=174442","More of this: URL URL",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['More of this:\n\nURL\n\nURL']",NA,0,"More of this:\n\nURL\n\nURL" 544,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","*** Bug 49573 has been marked as a duplicate of this bug. ***",1371214602,"PHID-USER-3uecblbxq24ycewm2cog","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","*** Bug 49573 has been marked as a duplicate of this bug. ***","*** Bug 49573 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['*** Bug 49573 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 49573 has been marked as a duplicate of this bug." 544,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","*** Bug 49573 has been marked as a duplicate of this bug. ***",1371214602,"PHID-USER-3uecblbxq24ycewm2cog","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","*** Bug 49573 has been marked as a duplicate of this bug. ***","*** Bug 49573 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['*** Bug 49573 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 629,"VisualEditor: Message should be displayed for anonymous users in the alerts box","Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",1367266320,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bkkyo5d2dquufftw2sz","task_description","VisualEditor: Message should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Message should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","Unbreak Now!",100,1367602898,NA,"resolved","True","c1",1,"True","False",-9,NA,"['VisualEditor: Message should be displayed for anonymous users in the alerts box.', ""Currently we don't alert users that they're outing their IP when they save."", 'This is a Bad Thing(tm).', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"VisualEditor: Message should be displayed for anonymous users in the alerts box." 629,"VisualEditor: Message should be displayed for anonymous users in the alerts box","Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",1367266320,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bkkyo5d2dquufftw2sz","task_description","VisualEditor: Message should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Message should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","Unbreak Now!",100,1367602898,NA,"resolved","True","c1",1,"True","False",-9,NA,"['VisualEditor: Message should be displayed for anonymous users in the alerts box.', ""Currently we don't alert users that they're outing their IP when they save."", 'This is a Bad Thing(tm).', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"This is a Bad Thing(tm)." 629,"VisualEditor: Message should be displayed for anonymous users in the alerts box","Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",1367266320,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bkkyo5d2dquufftw2sz","task_description","VisualEditor: Message should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Message should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","Unbreak Now!",100,1367602898,NA,"resolved","True","c1",1,"True","False",-9,NA,"['VisualEditor: Message should be displayed for anonymous users in the alerts box.', ""Currently we don't alert users that they're outing their IP when they save."", 'This is a Bad Thing(tm).', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: critical" 629,"VisualEditor: Message should be displayed for anonymous users in the alerts box","Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",1367266320,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bkkyo5d2dquufftw2sz","task_description","VisualEditor: Message should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Message should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","Unbreak Now!",100,1367602898,NA,"resolved","True","c1",1,"True","False",-9,NA,"['VisualEditor: Message should be displayed for anonymous users in the alerts box.', ""Currently we don't alert users that they're outing their IP when they save."", 'This is a Bad Thing(tm).', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"Currently we don't alert users that they're outing their IP when they save." 630,"VisualEditor: Message should be displayed for anonymous users in the alerts box","I see - wan't looking at main namespace.",1367604012,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","I see - wan't looking at main namespace.","I see - wan't looking at main namespace.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"[""I see - wan't looking at main namespace.""]",NA,0,"I see - wan't looking at main namespace." 631,"VisualEditor: Message should be displayed for anonymous users in the alerts box","Merged and will go out with wmf4.",1367602898,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","Merged and will go out with wmf4.","Merged and will go out with wmf4.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['Merged and will go out with wmf4.']",NA,0,"Merged and will go out with wmf4." 632,"VisualEditor: Message should be displayed for anonymous users in the alerts box","(In reply to comment #4) > mediawiki.org? I don't see it there. Compare https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21&action=edit with https://www.mediawiki.org/wiki/MediaWiki_1.21?veaction=edit in an isolated browser (e.g. Chrome Incognito).",1367599367,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","(In reply to comment #4) > mediawiki.org? I don't see it there. Compare https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21&action=edit with https://www.mediawiki.org/wiki/MediaWiki_1.21?veaction=edit in an isolated browser (e.g. Chrome Incognito).","(In reply to comment #4) QUOTE Compare URL with URL in an isolated browser (e.g. Chrome Incognito).",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['(In reply to comment #4)\nQUOTE\n\nCompare URL with URL in an isolated browser (e.g.', 'Chrome Incognito).']",NA,0,"(In reply to comment #4)\nQUOTE\n\nCompare URL with URL in an isolated browser (e.g." 632,"VisualEditor: Message should be displayed for anonymous users in the alerts box","(In reply to comment #4) > mediawiki.org? I don't see it there. Compare https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21&action=edit with https://www.mediawiki.org/wiki/MediaWiki_1.21?veaction=edit in an isolated browser (e.g. Chrome Incognito).",1367599367,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","(In reply to comment #4) > mediawiki.org? I don't see it there. Compare https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21&action=edit with https://www.mediawiki.org/wiki/MediaWiki_1.21?veaction=edit in an isolated browser (e.g. Chrome Incognito).","(In reply to comment #4) QUOTE Compare URL with URL in an isolated browser (e.g. Chrome Incognito).",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['(In reply to comment #4)\nQUOTE\n\nCompare URL with URL in an isolated browser (e.g.', 'Chrome Incognito).']",NA,0,"Chrome Incognito)." 633,"VisualEditor: Message should be displayed for anonymous users in the alerts box","mediawiki.org? I don't see it there.",1367598917,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","mediawiki.org? I don't see it there.","mediawiki.org? I don't see it there.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['mediawiki.org?', ""I don't see it there.""]",NA,0,"mediawiki.org?" 633,"VisualEditor: Message should be displayed for anonymous users in the alerts box","mediawiki.org? I don't see it there.",1367598917,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","mediawiki.org? I don't see it there.","mediawiki.org? I don't see it there.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['mediawiki.org?', ""I don't see it there.""]",NA,0,"I don't see it there." 634,"VisualEditor: Message should be displayed for anonymous users in the alerts box","(In reply to comment #2) > Currently the extension doesn't let anon editors use it at all ( > $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've > put in a fix for when we do. Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)",1367594947,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","(In reply to comment #2) > Currently the extension doesn't let anon editors use it at all ( > $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've > put in a fix for when we do. Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)","(In reply to comment #2) QUOTE QUOTE QUOTE Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"[""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nExcept for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference."", ':-)']",NA,0,":-)" 634,"VisualEditor: Message should be displayed for anonymous users in the alerts box","(In reply to comment #2) > Currently the extension doesn't let anon editors use it at all ( > $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've > put in a fix for when we do. Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)",1367594947,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","(In reply to comment #2) > Currently the extension doesn't let anon editors use it at all ( > $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've > put in a fix for when we do. Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)","(In reply to comment #2) QUOTE QUOTE QUOTE Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"[""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nExcept for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference."", ':-)']",NA,0,"(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nExcept for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference." 635,"VisualEditor: Message should be displayed for anonymous users in the alerts box","Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.",1367577948,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.","Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"[""Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.""]",NA,0,"Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do." 636,"VisualEditor: Message should be displayed for anonymous users in the alerts box","Related URL: https://gerrit.wikimedia.org/r/62143 (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0)",1367577674,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-5bkkyo5d2dquufftw2sz","task_subcomment","Related URL: https://gerrit.wikimedia.org/r/62143 (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0)","Related URL: GERRIT_URL (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0)",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-9,NA,"['Related URL: GERRIT_URL (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0)']",NA,0,"Related URL: GERRIT_URL (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0)" 843,"VisualEditor: Edit summary field loses focus when pasting (Firefox)","When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",1378792920,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-pdpn7hvlculri4ccy42t","task_description","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1393634141,NA,"resolved","True","c1",3,"False","False",10,NA,"['VisualEditor: Edit summary field loses focus when pasting (Firefox).', 'When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.', 'Possibly related to bug 53632??', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"VisualEditor: Edit summary field loses focus when pasting (Firefox)." 843,"VisualEditor: Edit summary field loses focus when pasting (Firefox)","When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",1378792920,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-pdpn7hvlculri4ccy42t","task_description","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1393634141,NA,"resolved","True","c1",3,"False","False",10,NA,"['VisualEditor: Edit summary field loses focus when pasting (Firefox).', 'When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.', 'Possibly related to bug 53632??', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus." 843,"VisualEditor: Edit summary field loses focus when pasting (Firefox)","When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",1378792920,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-pdpn7hvlculri4ccy42t","task_description","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1393634141,NA,"resolved","True","c1",3,"False","False",10,NA,"['VisualEditor: Edit summary field loses focus when pasting (Firefox).', 'When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.', 'Possibly related to bug 53632??', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Possibly related to bug 53632??" 843,"VisualEditor: Edit summary field loses focus when pasting (Firefox)","When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",1378792920,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-pdpn7hvlculri4ccy42t","task_description","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1393634141,NA,"resolved","True","c1",3,"False","False",10,NA,"['VisualEditor: Edit summary field loses focus when pasting (Firefox).', 'When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.', 'Possibly related to bug 53632??', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal" 844,"VisualEditor: Edit summary field loses focus when pasting (Firefox)","Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.",1393634141,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-pdpn7hvlculri4ccy42t","task_subcomment","Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.","Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,34,NA,"['Now that the edit summary is in its own window, this bug has gone away.', ""I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.""]",NA,0,"Now that the edit summary is in its own window, this bug has gone away." 844,"VisualEditor: Edit summary field loses focus when pasting (Firefox)","Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.",1393634141,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-pdpn7hvlculri4ccy42t","task_subcomment","Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.","Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,34,NA,"['Now that the edit summary is in its own window, this bug has gone away.', ""I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.""]",NA,0,"I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear." 882,"VisualEditor: Show and make editable , and tags","There is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",1378049580,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-brld2i7xjlh2vp4m2jxn","task_description","VisualEditor: Show and make editable , and tags./n/nThere is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603","VisualEditor: Show and make editable , and tags./n/nThere is discussion at URL about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL URL","Needs Triage",90,1390023864,NA,"declined","True","c1",3,"False","False",8,NA,"['VisualEditor: Show and make editable , and tags.', 'There is discussion at URL about using the edit filter to block edits adding the tag in mainspace.', 'However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit.', 'They can\'t find the nowiki tag, as it is invisible.""', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL']",FALSE,0,"VisualEditor: Show and make editable , and tags." 882,"VisualEditor: Show and make editable , and tags","There is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",1378049580,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-brld2i7xjlh2vp4m2jxn","task_description","VisualEditor: Show and make editable , and tags./n/nThere is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603","VisualEditor: Show and make editable , and tags./n/nThere is discussion at URL about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL URL","Needs Triage",90,1390023864,NA,"declined","True","c1",3,"False","False",8,NA,"['VisualEditor: Show and make editable , and tags.', 'There is discussion at URL about using the edit filter to block edits adding the tag in mainspace.', 'However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit.', 'They can\'t find the nowiki tag, as it is invisible.""', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL']",FALSE,0,"There is discussion at URL about using the edit filter to block edits adding the tag in mainspace." 882,"VisualEditor: Show and make editable , and tags","There is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",1378049580,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-brld2i7xjlh2vp4m2jxn","task_description","VisualEditor: Show and make editable , and tags./n/nThere is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603","VisualEditor: Show and make editable , and tags./n/nThere is discussion at URL about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL URL","Needs Triage",90,1390023864,NA,"declined","True","c1",3,"False","False",8,NA,"['VisualEditor: Show and make editable , and tags.', 'There is discussion at URL about using the edit filter to block edits adding the tag in mainspace.', 'However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit.', 'They can\'t find the nowiki tag, as it is invisible.""', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL']",FALSE,0,"However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit." 882,"VisualEditor: Show and make editable , and tags","There is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",1378049580,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-brld2i7xjlh2vp4m2jxn","task_description","VisualEditor: Show and make editable , and tags./n/nThere is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603","VisualEditor: Show and make editable , and tags./n/nThere is discussion at URL about using the edit filter to block edits adding the tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL URL","Needs Triage",90,1390023864,NA,"declined","True","c1",3,"False","False",8,NA,"['VisualEditor: Show and make editable , and tags.', 'There is discussion at URL about using the edit filter to block edits adding the tag in mainspace.', 'However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit.', 'They can\'t find the nowiki tag, as it is invisible.""', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL']",FALSE,0,"They can\" 883,"VisualEditor: Show and make editable , and tags","WONTFIXing this bug instead: is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a in).",1390023864,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-brld2i7xjlh2vp4m2jxn","task_subcomment","WONTFIXing this bug instead: is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a in).","WONTFIXing this bug instead: is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a in).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,28,NA,"['WONTFIXing this bug instead:\n\n is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed.', 'Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a in).']",NA,0,"WONTFIXing this bug instead:\n\n is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed." 883,"VisualEditor: Show and make editable , and tags","WONTFIXing this bug instead: is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a in).",1390023864,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-brld2i7xjlh2vp4m2jxn","task_subcomment","WONTFIXing this bug instead: is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a in).","WONTFIXing this bug instead: is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a in).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,28,NA,"['WONTFIXing this bug instead:\n\n is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed.', 'Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a in).']",NA,0,"Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a in)." 884,"VisualEditor: Show and make editable , and tags","Gah, sorry, wrong bug.",1390023748,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-brld2i7xjlh2vp4m2jxn","task_subcomment","Gah, sorry, wrong bug.","Gah, sorry, wrong bug.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,28,NA,"['Gah, sorry, wrong bug.']",NA,0,"Gah, sorry, wrong bug." 885,"VisualEditor: Show and make editable , and tags","This is because (unlike s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***",1390023708,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-brld2i7xjlh2vp4m2jxn","task_subcomment","This is because (unlike s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***","This is because (unlike s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,28,NA,"['This is because (unlike s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381.', '*** This bug has been marked as a duplicate of bug 56381 ***']",NA,0,"This is because (unlike s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381." 885,"VisualEditor: Show and make editable , and tags","This is because (unlike s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***",1390023708,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-brld2i7xjlh2vp4m2jxn","task_subcomment","This is because (unlike s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***","This is because (unlike s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,28,NA,"['This is because (unlike s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381.', '*** This bug has been marked as a duplicate of bug 56381 ***']",NA,0,"*** This bug has been marked as a duplicate of bug 56381 ***" 1319,"VE: Page settings: Languages list cut off","Screenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box Original Bug title: VE: Page settings: Languages list cut off In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of .ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) over .ve-ui-panelLayout-scrollable (setting overflow-y:auto) -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11501}",1374481140,"PHID-USER-fgjrqsoj4hk6ezzjdea4","PHID-TASK-kuzyc5hs4c2r4b2fex4f","task_description","VE: Page settings: Languages list cut off./n/nScreenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box Original Bug title: VE: Page settings: Languages list cut off In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of .ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) over .ve-ui-panelLayout-scrollable (setting overflow-y:auto) -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11501}","VE: Page settings: Languages list cut off./n/nScreenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box Original Bug title: VE: Page settings: Languages list cut off In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of .ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) over .ve-ui-panelLayout-scrollable (setting overflow-y:auto) -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11501}","Needs Triage",90,1374489509,NA,"resolved","True","c1",3,"False","False",3,NA,"['VE: Page settings: Languages list cut off.', 'Screenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box\n\nOriginal Bug title: VE: Page settings: Languages list cut off\n\nIn the page settings dialog, the languages list is not completely visible.', 'This is due to the higher CSS selector precedence of \n.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) \nover \n.ve-ui-panelLayout-scrollable (setting overflow-y:auto)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11501}']",TRUE,0,"VE: Page settings: Languages list cut off." 1319,"VE: Page settings: Languages list cut off","Screenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box Original Bug title: VE: Page settings: Languages list cut off In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of .ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) over .ve-ui-panelLayout-scrollable (setting overflow-y:auto) -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11501}",1374481140,"PHID-USER-fgjrqsoj4hk6ezzjdea4","PHID-TASK-kuzyc5hs4c2r4b2fex4f","task_description","VE: Page settings: Languages list cut off./n/nScreenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box Original Bug title: VE: Page settings: Languages list cut off In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of .ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) over .ve-ui-panelLayout-scrollable (setting overflow-y:auto) -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11501}","VE: Page settings: Languages list cut off./n/nScreenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box Original Bug title: VE: Page settings: Languages list cut off In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of .ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) over .ve-ui-panelLayout-scrollable (setting overflow-y:auto) -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11501}","Needs Triage",90,1374489509,NA,"resolved","True","c1",3,"False","False",3,NA,"['VE: Page settings: Languages list cut off.', 'Screenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box\n\nOriginal Bug title: VE: Page settings: Languages list cut off\n\nIn the page settings dialog, the languages list is not completely visible.', 'This is due to the higher CSS selector precedence of \n.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) \nover \n.ve-ui-panelLayout-scrollable (setting overflow-y:auto)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11501}']",TRUE,0,"Screenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box\n\nOriginal Bug title: VE: Page settings: Languages list cut off\n\nIn the page settings dialog, the languages list is not completely visible." 1319,"VE: Page settings: Languages list cut off","Screenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box Original Bug title: VE: Page settings: Languages list cut off In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of .ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) over .ve-ui-panelLayout-scrollable (setting overflow-y:auto) -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11501}",1374481140,"PHID-USER-fgjrqsoj4hk6ezzjdea4","PHID-TASK-kuzyc5hs4c2r4b2fex4f","task_description","VE: Page settings: Languages list cut off./n/nScreenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box Original Bug title: VE: Page settings: Languages list cut off In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of .ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) over .ve-ui-panelLayout-scrollable (setting overflow-y:auto) -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11501}","VE: Page settings: Languages list cut off./n/nScreenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box Original Bug title: VE: Page settings: Languages list cut off In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of .ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) over .ve-ui-panelLayout-scrollable (setting overflow-y:auto) -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11501}","Needs Triage",90,1374489509,NA,"resolved","True","c1",3,"False","False",3,NA,"['VE: Page settings: Languages list cut off.', 'Screenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box\n\nOriginal Bug title: VE: Page settings: Languages list cut off\n\nIn the page settings dialog, the languages list is not completely visible.', 'This is due to the higher CSS selector precedence of \n.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) \nover \n.ve-ui-panelLayout-scrollable (setting overflow-y:auto)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11501}']",TRUE,0,"This is due to the higher CSS selector precedence of \n.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) \nover \n.ve-ui-panelLayout-scrollable (setting overflow-y:auto)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11501}" 1320,"VE: Page settings: Languages list cut off","Change 75083 abandoned by Rillke: Adding important to overflow:auto on scrollable elements Reason: Fixed by If2d5ec3168a874eb4f856450583d6c89967513df https://gerrit.wikimedia.org/r/75083",1374513446,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-kuzyc5hs4c2r4b2fex4f","task_subcomment","Change 75083 abandoned by Rillke: Adding important to overflow:auto on scrollable elements Reason: Fixed by If2d5ec3168a874eb4f856450583d6c89967513df https://gerrit.wikimedia.org/r/75083","Change 75083 abandoned by Rillke: Adding important to overflow:auto on scrollable elements Reason: Fixed by If2d5ec3168a874eb4f856450583d6c89967513df GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Change 75083 abandoned by Rillke:\nAdding important to overflow:auto on scrollable elements\n\nReason:\nFixed by If2d5ec3168a874eb4f856450583d6c89967513df\n\nGERRIT_URL']",NA,0,"Change 75083 abandoned by Rillke:\nAdding important to overflow:auto on scrollable elements\n\nReason:\nFixed by If2d5ec3168a874eb4f856450583d6c89967513df\n\nGERRIT_URL" 1321,"VE: Page settings: Languages list cut off","I'm pretty sure it's the same issue as on bug 51739. *** This bug has been marked as a duplicate of bug 51739 ***",1374489509,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-kuzyc5hs4c2r4b2fex4f","task_subcomment","I'm pretty sure it's the same issue as on bug 51739. *** This bug has been marked as a duplicate of bug 51739 ***","I'm pretty sure it's the same issue as on bug 51739. *** This bug has been marked as a duplicate of bug 51739 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"[""I'm pretty sure it's the same issue as on bug 51739."", '*** This bug has been marked as a duplicate of bug 51739 ***']",NA,0,"*** This bug has been marked as a duplicate of bug 51739 ***" 1321,"VE: Page settings: Languages list cut off","I'm pretty sure it's the same issue as on bug 51739. *** This bug has been marked as a duplicate of bug 51739 ***",1374489509,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-kuzyc5hs4c2r4b2fex4f","task_subcomment","I'm pretty sure it's the same issue as on bug 51739. *** This bug has been marked as a duplicate of bug 51739 ***","I'm pretty sure it's the same issue as on bug 51739. *** This bug has been marked as a duplicate of bug 51739 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"[""I'm pretty sure it's the same issue as on bug 51739."", '*** This bug has been marked as a duplicate of bug 51739 ***']",NA,0,"I'm pretty sure it's the same issue as on bug 51739." 1322,"VE: Page settings: Languages list cut off","Change 75083 had a related patch set uploaded by Rillke: Adding important to overflow:auto on scrollable elements https://gerrit.wikimedia.org/r/75083",1374487397,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-kuzyc5hs4c2r4b2fex4f","task_subcomment","Change 75083 had a related patch set uploaded by Rillke: Adding important to overflow:auto on scrollable elements https://gerrit.wikimedia.org/r/75083","Change 75083 had a related patch set uploaded by Rillke: Adding important to overflow:auto on scrollable elements GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Change 75083 had a related patch set uploaded by Rillke:\nAdding important to overflow:auto on scrollable elements\n\nGERRIT_URL']",NA,0,"Change 75083 had a related patch set uploaded by Rillke:\nAdding important to overflow:auto on scrollable elements\n\nGERRIT_URL" 1592,"Nested s considered harmful","Sometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387",1373055060,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-lb7abq7fkyxs3qzwp4ty","task_description","Nested s considered harmful./n/nSometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387","Nested s considered harmful./n/nSometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL","Needs Triage",90,1373314749,NA,"resolved","True","c1",3,"True","False",0,NA,"['Nested s considered harmful.', 'Sometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor.', ':-)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"Nested s considered harmful." 1592,"Nested s considered harmful","Sometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387",1373055060,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-lb7abq7fkyxs3qzwp4ty","task_description","Nested s considered harmful./n/nSometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387","Nested s considered harmful./n/nSometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL","Needs Triage",90,1373314749,NA,"resolved","True","c1",3,"True","False",0,NA,"['Nested s considered harmful.', 'Sometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor.', ':-)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"Sometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor." 1592,"Nested s considered harmful","Sometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387",1373055060,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-lb7abq7fkyxs3qzwp4ty","task_description","Nested s considered harmful./n/nSometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387","Nested s considered harmful./n/nSometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL","Needs Triage",90,1373314749,NA,"resolved","True","c1",3,"True","False",0,NA,"['Nested s considered harmful.', 'Sometimes Parsoid will wrap a around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor.', ':-)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,":-)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL" 1593,"Nested s considered harmful","*** Bug 50724 has been marked as a duplicate of this bug. ***",1373637242,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-lb7abq7fkyxs3qzwp4ty","task_subcomment","*** Bug 50724 has been marked as a duplicate of this bug. ***","*** Bug 50724 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['*** Bug 50724 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50724 has been marked as a duplicate of this bug." 1593,"Nested s considered harmful","*** Bug 50724 has been marked as a duplicate of this bug. ***",1373637242,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-lb7abq7fkyxs3qzwp4ty","task_subcomment","*** Bug 50724 has been marked as a duplicate of this bug. ***","*** Bug 50724 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['*** Bug 50724 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 1594,"Nested s considered harmful","Change 72971 merged by jenkins-bot: Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params https://gerrit.wikimedia.org/r/72971",1373473754,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-lb7abq7fkyxs3qzwp4ty","task_subcomment","Change 72971 merged by jenkins-bot: Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params https://gerrit.wikimedia.org/r/72971","Change 72971 merged by jenkins-bot: Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Change 72971 merged by jenkins-bot:\nTry #2: (Bug 50835) Dont nowiki escape already escaped tpl params\n\nGERRIT_URL']",NA,0,"Change 72971 merged by jenkins-bot:\nTry #2: (Bug 50835) Dont nowiki escape already escaped tpl params\n\nGERRIT_URL" 1595,"Nested s considered harmful","Change 72971 had a related patch set uploaded by Subramanya Sastry: Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params https://gerrit.wikimedia.org/r/72971",1373470917,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-lb7abq7fkyxs3qzwp4ty","task_subcomment","Change 72971 had a related patch set uploaded by Subramanya Sastry: Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params https://gerrit.wikimedia.org/r/72971","Change 72971 had a related patch set uploaded by Subramanya Sastry: Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Change 72971 had a related patch set uploaded by Subramanya Sastry:\nTry #2: (Bug 50835) Dont nowiki escape already escaped tpl params\n\nGERRIT_URL']",NA,0,"Change 72971 had a related patch set uploaded by Subramanya Sastry:\nTry #2: (Bug 50835) Dont nowiki escape already escaped tpl params\n\nGERRIT_URL" 1596,"Nested s considered harmful","Change 72230 merged by jenkins-bot: (Bug 50835) Dont nowiki escape already escaped template params https://gerrit.wikimedia.org/r/72230",1373307265,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-lb7abq7fkyxs3qzwp4ty","task_subcomment","Change 72230 merged by jenkins-bot: (Bug 50835) Dont nowiki escape already escaped template params https://gerrit.wikimedia.org/r/72230","Change 72230 merged by jenkins-bot: (Bug 50835) Dont nowiki escape already escaped template params GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Change 72230 merged by jenkins-bot:\n(Bug 50835) Dont nowiki escape already escaped template params\n\nGERRIT_URL']",NA,0,"Change 72230 merged by jenkins-bot:\n(Bug 50835) Dont nowiki escape already escaped template params\n\nGERRIT_URL" 1597,"Nested s considered harmful","Change 72230 had a related patch set uploaded by Subramanya Sastry: (Bug 50835) Dont nowiki escape already escaped template params https://gerrit.wikimedia.org/r/72230",1373065523,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-lb7abq7fkyxs3qzwp4ty","task_subcomment","Change 72230 had a related patch set uploaded by Subramanya Sastry: (Bug 50835) Dont nowiki escape already escaped template params https://gerrit.wikimedia.org/r/72230","Change 72230 had a related patch set uploaded by Subramanya Sastry: (Bug 50835) Dont nowiki escape already escaped template params GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Change 72230 had a related patch set uploaded by Subramanya Sastry:\n(Bug 50835) Dont nowiki escape already escaped template params\n\nGERRIT_URL']",NA,0,"Change 72230 had a related patch set uploaded by Subramanya Sastry:\n(Bug 50835) Dont nowiki escape already escaped template params\n\nGERRIT_URL" 1809,"Unwanted Removal of text formatting","In this edit:https://en.wikipedia.org/w/index.php?title=Blepsias_cirrhosus&diff=next&oldid=561719692 Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:http://en.wikipedia.org/wiki/User_talk:PBASH607#VE_issues.3F -------------------------- **Version**: unspecified **Severity**: major",1372280520,"PHID-USER-ttyyrgsrkyonct7hizgv","PHID-TASK-ytqjgzoe2nidan525q6p","task_description","Unwanted Removal of text formatting./n/nIn this edit:https://en.wikipedia.org/w/index.php?title=Blepsias_cirrhosus&diff=next&oldid=561719692 Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:http://en.wikipedia.org/wiki/User_talk:PBASH607#VE_issues.3F -------------------------- **Version**: unspecified **Severity**: major","Unwanted Removal of text formatting./n/nIn this edit:URL Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:URL -------------------------- **Version**: unspecified **Severity**: major","Needs Triage",90,1372284454,NA,"resolved","True","c1",2,"False","False",-1,NA,"['Unwanted Removal of text formatting.', 'In this edit:URL\n\nBold/italic formatting was removed by an unrelated action (addition of text).', ""See editor's description here:URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major""]",TRUE,0,"Unwanted Removal of text formatting." 1809,"Unwanted Removal of text formatting","In this edit:https://en.wikipedia.org/w/index.php?title=Blepsias_cirrhosus&diff=next&oldid=561719692 Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:http://en.wikipedia.org/wiki/User_talk:PBASH607#VE_issues.3F -------------------------- **Version**: unspecified **Severity**: major",1372280520,"PHID-USER-ttyyrgsrkyonct7hizgv","PHID-TASK-ytqjgzoe2nidan525q6p","task_description","Unwanted Removal of text formatting./n/nIn this edit:https://en.wikipedia.org/w/index.php?title=Blepsias_cirrhosus&diff=next&oldid=561719692 Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:http://en.wikipedia.org/wiki/User_talk:PBASH607#VE_issues.3F -------------------------- **Version**: unspecified **Severity**: major","Unwanted Removal of text formatting./n/nIn this edit:URL Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:URL -------------------------- **Version**: unspecified **Severity**: major","Needs Triage",90,1372284454,NA,"resolved","True","c1",2,"False","False",-1,NA,"['Unwanted Removal of text formatting.', 'In this edit:URL\n\nBold/italic formatting was removed by an unrelated action (addition of text).', ""See editor's description here:URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major""]",TRUE,0,"In this edit:URL\n\nBold/italic formatting was removed by an unrelated action (addition of text)." 1809,"Unwanted Removal of text formatting","In this edit:https://en.wikipedia.org/w/index.php?title=Blepsias_cirrhosus&diff=next&oldid=561719692 Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:http://en.wikipedia.org/wiki/User_talk:PBASH607#VE_issues.3F -------------------------- **Version**: unspecified **Severity**: major",1372280520,"PHID-USER-ttyyrgsrkyonct7hizgv","PHID-TASK-ytqjgzoe2nidan525q6p","task_description","Unwanted Removal of text formatting./n/nIn this edit:https://en.wikipedia.org/w/index.php?title=Blepsias_cirrhosus&diff=next&oldid=561719692 Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:http://en.wikipedia.org/wiki/User_talk:PBASH607#VE_issues.3F -------------------------- **Version**: unspecified **Severity**: major","Unwanted Removal of text formatting./n/nIn this edit:URL Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:URL -------------------------- **Version**: unspecified **Severity**: major","Needs Triage",90,1372284454,NA,"resolved","True","c1",2,"False","False",-1,NA,"['Unwanted Removal of text formatting.', 'In this edit:URL\n\nBold/italic formatting was removed by an unrelated action (addition of text).', ""See editor's description here:URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major""]",TRUE,0,"See editor's description here:URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major" 1810,"Unwanted Removal of text formatting","Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us! *** This bug has been marked as a duplicate of bug 50068 ***",1372284454,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ytqjgzoe2nidan525q6p","task_subcomment","Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us! *** This bug has been marked as a duplicate of bug 50068 ***","Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us! *** This bug has been marked as a duplicate of bug 50068 ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug.', 'Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us!', '*** This bug has been marked as a duplicate of bug 50068 ***']",NA,0,"Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug." 1810,"Unwanted Removal of text formatting","Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us! *** This bug has been marked as a duplicate of bug 50068 ***",1372284454,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ytqjgzoe2nidan525q6p","task_subcomment","Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us! *** This bug has been marked as a duplicate of bug 50068 ***","Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us! *** This bug has been marked as a duplicate of bug 50068 ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug.', 'Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us!', '*** This bug has been marked as a duplicate of bug 50068 ***']",NA,0,"Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us!" 1810,"Unwanted Removal of text formatting","Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us! *** This bug has been marked as a duplicate of bug 50068 ***",1372284454,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ytqjgzoe2nidan525q6p","task_subcomment","Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us! *** This bug has been marked as a duplicate of bug 50068 ***","Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us! *** This bug has been marked as a duplicate of bug 50068 ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug.', 'Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us!', '*** This bug has been marked as a duplicate of bug 50068 ***']",NA,0,"*** This bug has been marked as a duplicate of bug 50068 ***" 1811,"Unwanted Removal of text formatting","Duplicated here: http://test.wikipedia.org/w/index.php?title=VisualEditor%3ATestingGrounds&diff=174932&oldid=174931",1372283768,"PHID-USER-ttyyrgsrkyonct7hizgv","PHID-TASK-ytqjgzoe2nidan525q6p","task_subcomment","Duplicated here: http://test.wikipedia.org/w/index.php?title=VisualEditor%3ATestingGrounds&diff=174932&oldid=174931","Duplicated here: URL",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-1,NA,"['Duplicated here: URL']",NA,0,"Duplicated here: URL" 1964,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting","See (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 -------------------------- **Version**: unspecified **Severity**: normal",1371574560,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-kybodyavmyonstmof6sr","task_description","VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) URL -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1371574643,NA,"resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting.', 'See (ferinstance) URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting." 1964,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting","See (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 -------------------------- **Version**: unspecified **Severity**: normal",1371574560,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-kybodyavmyonstmof6sr","task_description","VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) URL -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1371574643,NA,"resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting.', 'See (ferinstance) URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"See (ferinstance) URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal" 1965,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting"," %%%*** This bug has been marked as a duplicate of bug 49755 ***%%%",1371574643,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-kybodyavmyonstmof6sr","task_subcomment"," %%%*** This bug has been marked as a duplicate of bug 49755 ***%%%"," %%%*** This bug has been marked as a duplicate of bug 49755 ***%%%",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-2,NA,"['\n\n%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%']",NA,1,"\n\n%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%" 2061,"VisualEditor misrepresents linked files as embedded inline, when editing","**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal",1369114380,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-6nrh4cee4ez6cwykweo5","task_description","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** CODE **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1369114571,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page.', 'While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text.', '(Screenshots of the error and associated markup to be attached.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor misrepresents linked files as embedded inline, when editing." 2061,"VisualEditor misrepresents linked files as embedded inline, when editing","**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal",1369114380,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-6nrh4cee4ez6cwykweo5","task_description","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** CODE **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1369114571,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page.', 'While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text.', '(Screenshots of the error and associated markup to be attached.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"**Author:** CODE\n\n**Description:**\nPlacing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page." 2061,"VisualEditor misrepresents linked files as embedded inline, when editing","**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal",1369114380,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-6nrh4cee4ez6cwykweo5","task_description","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** CODE **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1369114571,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page.', 'While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text.', '(Screenshots of the error and associated markup to be attached.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text." 2061,"VisualEditor misrepresents linked files as embedded inline, when editing","**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal",1369114380,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-6nrh4cee4ez6cwykweo5","task_description","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** CODE **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1369114571,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page.', 'While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text.', '(Screenshots of the error and associated markup to be attached.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"(Screenshots of the error and associated markup to be attached.)" 2061,"VisualEditor misrepresents linked files as embedded inline, when editing","**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal",1369114380,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-6nrh4cee4ez6cwykweo5","task_description","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** `swalling` **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**Author:** CODE **Description:** Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.) -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1369114571,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page.', 'While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text.', '(Screenshots of the error and associated markup to be attached.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal" 2062,"VisualEditor misrepresents linked files as embedded inline, when editing"," *** This bug has been marked as a duplicate of bug 48387 ***",1369114571,"PHID-USER-hyfm4swq76s4j642w46x","PHID-TASK-6nrh4cee4ez6cwykweo5","task_subcomment"," *** This bug has been marked as a duplicate of bug 48387 ***"," *** This bug has been marked as a duplicate of bug 48387 ***",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['\n\n*** This bug has been marked as a duplicate of bug 48387 ***']",NA,0,"\n\n*** This bug has been marked as a duplicate of bug 48387 ***" 2063,"VisualEditor misrepresents linked files as embedded inline, when editing","**swalling** wrote: Screenshot of markup **Attached**: {F10438}",1369114456,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-6nrh4cee4ez6cwykweo5","task_subcomment","**swalling** wrote: Screenshot of markup **Attached**: {F10438}","**swalling** wrote: Screenshot of markup **Attached**: {F10438}",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['**swalling** wrote:\n\nScreenshot of markup\n\n**Attached**: {F10438}']",NA,0,"**swalling** wrote:\n\nScreenshot of markup\n\n**Attached**: {F10438}" 2064,"VisualEditor misrepresents linked files as embedded inline, when editing","**swalling** wrote: Edit mode, with incorrect thumbnails **Attached**: {F10437}",1369114431,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-6nrh4cee4ez6cwykweo5","task_subcomment","**swalling** wrote: Edit mode, with incorrect thumbnails **Attached**: {F10437}","**swalling** wrote: Edit mode, with incorrect thumbnails **Attached**: {F10437}",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['**swalling** wrote:\n\nEdit mode, with incorrect thumbnails\n\n**Attached**: {F10437}']",NA,0,"**swalling** wrote:\n\nEdit mode, with incorrect thumbnails\n\n**Attached**: {F10437}" 2173,"Parsoid: Tables don't round-trip cleanly","See http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal",1360879800,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-2lufxleaemvynes2b2da","task_description","Parsoid: Tables don't round-trip cleanly./n/nSee http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Parsoid: Tables don't round-trip cleanly./n/nSee URL for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1360889187,NA,"declined","True","c1",1,"False","False",-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", 'See URL for example.', ""(This URL currently doesn't work because the /mw prefix disappeared in a recent change.)"", '* border=""1"" is normalized to border=1, but only in the table\'s attributes, not in the rows\' attributes\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"See URL for example." 2173,"Parsoid: Tables don't round-trip cleanly","See http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal",1360879800,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-2lufxleaemvynes2b2da","task_description","Parsoid: Tables don't round-trip cleanly./n/nSee http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Parsoid: Tables don't round-trip cleanly./n/nSee URL for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1360889187,NA,"declined","True","c1",1,"False","False",-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", 'See URL for example.', ""(This URL currently doesn't work because the /mw prefix disappeared in a recent change.)"", '* border=""1"" is normalized to border=1, but only in the table\'s attributes, not in the rows\' attributes\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"* border=""1"" is normalized to border=1, but only in the table\" 2173,"Parsoid: Tables don't round-trip cleanly","See http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal",1360879800,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-2lufxleaemvynes2b2da","task_description","Parsoid: Tables don't round-trip cleanly./n/nSee http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Parsoid: Tables don't round-trip cleanly./n/nSee URL for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1360889187,NA,"declined","True","c1",1,"False","False",-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", 'See URL for example.', ""(This URL currently doesn't work because the /mw prefix disappeared in a recent change.)"", '* border=""1"" is normalized to border=1, but only in the table\'s attributes, not in the rows\' attributes\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0," attributes\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal" 2173,"Parsoid: Tables don't round-trip cleanly","See http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal",1360879800,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-2lufxleaemvynes2b2da","task_description","Parsoid: Tables don't round-trip cleanly./n/nSee http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Parsoid: Tables don't round-trip cleanly./n/nSee URL for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1360889187,NA,"declined","True","c1",1,"False","False",-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", 'See URL for example.', ""(This URL currently doesn't work because the /mw prefix disappeared in a recent change.)"", '* border=""1"" is normalized to border=1, but only in the table\'s attributes, not in the rows\' attributes\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Parsoid: Tables don't round-trip cleanly." 2173,"Parsoid: Tables don't round-trip cleanly","See http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal",1360879800,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-2lufxleaemvynes2b2da","task_description","Parsoid: Tables don't round-trip cleanly./n/nSee http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Parsoid: Tables don't round-trip cleanly./n/nSee URL for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.) * border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes * | rowspan=""3"" is normalized to |rowspan=""3"" -------------------------- **Version**: unspecified **Severity**: normal","Needs Triage",90,1360889187,NA,"declined","True","c1",1,"False","False",-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", 'See URL for example.', ""(This URL currently doesn't work because the /mw prefix disappeared in a recent change.)"", '* border=""1"" is normalized to border=1, but only in the table\'s attributes, not in the rows\' attributes\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"(This URL currently doesn't work because the /mw prefix disappeared in a recent change.)" 2174,"Parsoid: Tables don't round-trip cleanly","The first normalization is actually the other way around: border=1 is normalized to border=""1"". This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.",1360889187,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-2lufxleaemvynes2b2da","task_subcomment","The first normalization is actually the other way around: border=1 is normalized to border=""1"". This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.","The first normalization is actually the other way around: border=1 is normalized to border=""1"". This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-20,NA,"['The first normalization is actually the other way around: border=1 is normalized to border=""1"".', 'This is the expected degree of normalization for non-selective serialization, so closing as wontfix.', ""Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.""]",NA,0,"The first normalization is actually the other way around: border=1 is normalized to border=""1""." 2174,"Parsoid: Tables don't round-trip cleanly","The first normalization is actually the other way around: border=1 is normalized to border=""1"". This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.",1360889187,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-2lufxleaemvynes2b2da","task_subcomment","The first normalization is actually the other way around: border=1 is normalized to border=""1"". This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.","The first normalization is actually the other way around: border=1 is normalized to border=""1"". This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-20,NA,"['The first normalization is actually the other way around: border=1 is normalized to border=""1"".', 'This is the expected degree of normalization for non-selective serialization, so closing as wontfix.', ""Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.""]",NA,0,"This is the expected degree of normalization for non-selective serialization, so closing as wontfix." 2174,"Parsoid: Tables don't round-trip cleanly","The first normalization is actually the other way around: border=1 is normalized to border=""1"". This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.",1360889187,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-2lufxleaemvynes2b2da","task_subcomment","The first normalization is actually the other way around: border=1 is normalized to border=""1"". This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.","The first normalization is actually the other way around: border=1 is normalized to border=""1"". This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-20,NA,"['The first normalization is actually the other way around: border=1 is normalized to border=""1"".', 'This is the expected degree of normalization for non-selective serialization, so closing as wontfix.', ""Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.""]",NA,0,"Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally." 2267,"VisualEditor: Inspector doesn't open properly","When you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place. -------------------------- **Version**: unspecified **Severity**: major",1355175300,"PHID-USER-mpfqwllylfkzpcgkdkvc","PHID-TASK-hydd4sggtsrxlgqhafqc","task_description","VisualEditor: Inspector doesn't open properly./n/nWhen you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place. -------------------------- **Version**: unspecified **Severity**: major","VisualEditor: Inspector doesn't open properly./n/nWhen you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place. -------------------------- **Version**: unspecified **Severity**: major","Needs Triage",90,1355189209,NA,"resolved","True","c1",0,"False","False",-29,NA,"[""VisualEditor: Inspector doesn't open properly."", ""When you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: major" 2267,"VisualEditor: Inspector doesn't open properly","When you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place. -------------------------- **Version**: unspecified **Severity**: major",1355175300,"PHID-USER-mpfqwllylfkzpcgkdkvc","PHID-TASK-hydd4sggtsrxlgqhafqc","task_description","VisualEditor: Inspector doesn't open properly./n/nWhen you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place. -------------------------- **Version**: unspecified **Severity**: major","VisualEditor: Inspector doesn't open properly./n/nWhen you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place. -------------------------- **Version**: unspecified **Severity**: major","Needs Triage",90,1355189209,NA,"resolved","True","c1",0,"False","False",-29,NA,"[""VisualEditor: Inspector doesn't open properly."", ""When you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"VisualEditor: Inspector doesn't open properly." 2267,"VisualEditor: Inspector doesn't open properly","When you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place. -------------------------- **Version**: unspecified **Severity**: major",1355175300,"PHID-USER-mpfqwllylfkzpcgkdkvc","PHID-TASK-hydd4sggtsrxlgqhafqc","task_description","VisualEditor: Inspector doesn't open properly./n/nWhen you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place. -------------------------- **Version**: unspecified **Severity**: major","VisualEditor: Inspector doesn't open properly./n/nWhen you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place. -------------------------- **Version**: unspecified **Severity**: major","Needs Triage",90,1355189209,NA,"resolved","True","c1",0,"False","False",-29,NA,"[""VisualEditor: Inspector doesn't open properly."", ""When you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"When you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place." 2268,"VisualEditor: Inspector doesn't open properly","*** Bug 37856 has been marked as a duplicate of this bug. ***",1355350453,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-hydd4sggtsrxlgqhafqc","task_subcomment","*** Bug 37856 has been marked as a duplicate of this bug. ***","*** Bug 37856 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-29,NA,"['*** Bug 37856 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 37856 has been marked as a duplicate of this bug." 2268,"VisualEditor: Inspector doesn't open properly","*** Bug 37856 has been marked as a duplicate of this bug. ***",1355350453,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-hydd4sggtsrxlgqhafqc","task_subcomment","*** Bug 37856 has been marked as a duplicate of this bug. ***","*** Bug 37856 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-29,NA,"['*** Bug 37856 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 2269,"VisualEditor: Inspector doesn't open properly","Fixed in gerrit 37945.",1355176593,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hydd4sggtsrxlgqhafqc","task_subcomment","Fixed in gerrit 37945.","Fixed in gerrit 37945.",NA,NA,NA,NA,NA,"True","c1",0,"True",NA,-29,NA,"['Fixed in gerrit 37945.']",NA,0,"Fixed in gerrit 37945." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"Firefox - Detected script lockup." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"Misplacing a bulleted / numbered list can cause a script lockup." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"- Click the ""Bulleted List"" button." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"A list bullet is added to the article." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"- Click right after the bullet that was just inserted." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"Now click the ""Bulleted list"" button again." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"Normally this would remove the bullet again." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"Instead of that both Firefox and Chrome seem to lock up." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"Cancelling the script allows you to regain browser control." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume." 3202,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}",1374695580,"PHID-USER-ohetl546bwt5ac2szu5w","PHID-TASK-ph24e22ltq2s3oztatem","task_description","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected. - Click the ""Bulleted List"" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11897}","High",80,1383848723,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).', 'Firefox - Detected script lockup.', 'Misplacing a bulleted / numbered list can cause a script lockup.', 'Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.', '- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.', '- Click the ""Bulleted List"" button.', 'A list bullet is added to the article.', '- Click right after the bullet that was just inserted.', 'Now click the ""Bulleted list"" button again.', 'Normally this would remove the bullet again.', 'Instead of that both Firefox and Chrome seem to lock up.', 'Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.', 'Cancelling the script allows you to regain browser control.', 'On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}" 3203,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.",1383848723,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.","Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,18,NA,"['Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.']",NA,0,"Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model." 3204,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","(In reply to comment #3) > Cannot reproduce it now with MAC OS using FireFox and Chrome. Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". > So changing the status of the bug as resolved. No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle",1383813525,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","(In reply to comment #3) > Cannot reproduce it now with MAC OS using FireFox and Chrome. Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". > So changing the status of the bug as resolved. No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle","(In reply to comment #3) QUOTE Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". QUOTE No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,18,NA,"['(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers.', 'Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".', 'QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED.', 'Also see URL']",NA,0,"(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers." 3204,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","(In reply to comment #3) > Cannot reproduce it now with MAC OS using FireFox and Chrome. Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". > So changing the status of the bug as resolved. No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle",1383813525,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","(In reply to comment #3) > Cannot reproduce it now with MAC OS using FireFox and Chrome. Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". > So changing the status of the bug as resolved. No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle","(In reply to comment #3) QUOTE Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". QUOTE No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,18,NA,"['(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers.', 'Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".', 'QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED.', 'Also see URL']",NA,0,"Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28""." 3204,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","(In reply to comment #3) > Cannot reproduce it now with MAC OS using FireFox and Chrome. Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". > So changing the status of the bug as resolved. No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle",1383813525,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","(In reply to comment #3) > Cannot reproduce it now with MAC OS using FireFox and Chrome. Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". > So changing the status of the bug as resolved. No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle","(In reply to comment #3) QUOTE Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". QUOTE No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,18,NA,"['(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers.', 'Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".', 'QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED.', 'Also see URL']",NA,0,"QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED." 3204,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","(In reply to comment #3) > Cannot reproduce it now with MAC OS using FireFox and Chrome. Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". > So changing the status of the bug as resolved. No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle",1383813525,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","(In reply to comment #3) > Cannot reproduce it now with MAC OS using FireFox and Chrome. Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". > So changing the status of the bug as resolved. No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle","(In reply to comment #3) QUOTE Please ALWAYS provide version information for browsers. Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"". QUOTE No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,18,NA,"['(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers.', 'Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".', 'QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED.', 'Also see URL']",NA,0,"Also see URL" 3205,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved. If you can still reproduce it ,please reopen the bug.",1383785800,"PHID-USER-24djtv3gj5gua2y6u2g5","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved. If you can still reproduce it ,please reopen the bug.","Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved. If you can still reproduce it ,please reopen the bug.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,18,NA,"['Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved.', 'If you can still reproduce it ,please reopen the bug.']",NA,0,"Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved." 3205,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved. If you can still reproduce it ,please reopen the bug.",1383785800,"PHID-USER-24djtv3gj5gua2y6u2g5","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved. If you can still reproduce it ,please reopen the bug.","Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved. If you can still reproduce it ,please reopen the bug.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,18,NA,"['Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved.', 'If you can still reproduce it ,please reopen the bug.']",NA,0,"If you can still reproduce it ,please reopen the bug." 3206,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","This is an infinite loop inside either Rangy or the bit of ContentEditable that calls it - lots of calls to sel.getRangeAt(index) which end up taking so long that the browser dies (?)",1380836632,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","This is an infinite loop inside either Rangy or the bit of ContentEditable that calls it - lots of calls to sel.getRangeAt(index) which end up taking so long that the browser dies (?)","This is an infinite loop inside either Rangy or the bit of ContentEditable that calls it - lots of calls to sel.getRangeAt(index) which end up taking so long that the browser dies (?)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['This is an infinite loop inside either Rangy or the bit of ContentEditable that calls it - lots of calls to sel.getRangeAt(index) which end up taking so long that the browser dies (?)']",NA,0,"This is an infinite loop inside either Rangy or the bit of ContentEditable that calls it - lots of calls to sel.getRangeAt(index) which end up taking so long that the browser dies (?)" 3207,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","We should have a 'crash' or 'dataloss' keyword. Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.",1380534678,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","We should have a 'crash' or 'dataloss' keyword. Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.","We should have a 'crash' or 'dataloss' keyword. Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"[""We should have a 'crash' or 'dataloss' keyword."", 'Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.']",NA,0,"Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways." 3207,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)","We should have a 'crash' or 'dataloss' keyword. Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.",1380534678,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-ph24e22ltq2s3oztatem","task_subcomment","We should have a 'crash' or 'dataloss' keyword. Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.","We should have a 'crash' or 'dataloss' keyword. Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"[""We should have a 'crash' or 'dataloss' keyword."", 'Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.']",NA,0,"We should have a 'crash' or 'dataloss' keyword." 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Note that this is not the same as bug 50715." 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play." 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"e.g." 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively." 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Having added ""mw.log(\" 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,", name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?)." 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Also weird that the callback is constantly triggered twice, once for null and once for the actual value." 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check." 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal" 3860,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_description","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1373497400,NA,"resolved","True","c1",3,"True","False",0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added." 3861,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.",1373497400,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-xwzbnkc2eempknw62ukj","task_subcomment","This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.","This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['This is now fixed in master and we will push to production very soon.', 'Sorry for the inconvenience.']",NA,0,"This is now fixed in master and we will push to production very soon." 3861,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.",1373497400,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-xwzbnkc2eempknw62ukj","task_subcomment","This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.","This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['This is now fixed in master and we will push to production very soon.', 'Sorry for the inconvenience.']",NA,0,"Sorry for the inconvenience." 3862,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Change 73010 merged by jenkins-bot: Retain original param names and ignore leading/trailing whitespace https://gerrit.wikimedia.org/r/73010",1373497076,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-xwzbnkc2eempknw62ukj","task_subcomment","Change 73010 merged by jenkins-bot: Retain original param names and ignore leading/trailing whitespace https://gerrit.wikimedia.org/r/73010","Change 73010 merged by jenkins-bot: Retain original param names and ignore leading/trailing whitespace GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Change 73010 merged by jenkins-bot:\nRetain original param names and ignore leading/trailing whitespace\n\nGERRIT_URL']",NA,0,"Change 73010 merged by jenkins-bot:\nRetain original param names and ignore leading/trailing whitespace\n\nGERRIT_URL" 3863,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Change 73010 had a related patch set uploaded by Trevor Parscal: Retain original param names and ignore leading/trailing whitespace https://gerrit.wikimedia.org/r/73010",1373483212,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-xwzbnkc2eempknw62ukj","task_subcomment","Change 73010 had a related patch set uploaded by Trevor Parscal: Retain original param names and ignore leading/trailing whitespace https://gerrit.wikimedia.org/r/73010","Change 73010 had a related patch set uploaded by Trevor Parscal: Retain original param names and ignore leading/trailing whitespace GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Change 73010 had a related patch set uploaded by Trevor Parscal:\nRetain original param names and ignore leading/trailing whitespace\n\nGERRIT_URL']",NA,0,"Change 73010 had a related patch set uploaded by Trevor Parscal:\nRetain original param names and ignore leading/trailing whitespace\n\nGERRIT_URL" 3864,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added","Working on this.",1372913735,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-xwzbnkc2eempknw62ukj","task_subcomment","Working on this.","Working on this.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"['Working on this.']",NA,0,"Working on this." 4103,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal",1372554600,"PHID-USER-2mkpm2voxepwvz7abjug","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_description","VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog./n/nAfter having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog./n/nAfter having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal","High",80,1384200108,NA,"resolved","True","c1",2,"False","False",-1,NA,"[""VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog."", 'After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template\n\ntest I made on beta was {{test|name = hello}}\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template\n\ntest I made on beta was {{test|name = hello}}\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal" 4103,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal",1372554600,"PHID-USER-2mkpm2voxepwvz7abjug","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_description","VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog./n/nAfter having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog./n/nAfter having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal","High",80,1384200108,NA,"resolved","True","c1",2,"False","False",-1,NA,"[""VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog."", 'After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template\n\ntest I made on beta was {{test|name = hello}}\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog." 4104,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.",1384200108,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.","Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,19,NA,"['Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such.', 'Please re-open if it recurs.']",NA,0,"Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such." 4104,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.",1384200108,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.","Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,19,NA,"['Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such.', 'Please re-open if it recurs.']",NA,0,"Please re-open if it recurs." 4105,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","Can't reproduce this bug.",1384198743,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","Can't reproduce this bug.","Can't reproduce this bug.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,19,NA,"[""Can't reproduce this bug.""]",NA,0,"Can't reproduce this bug." 4106,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","When I make a new template entry and open the template before I've saved the page, it looks like following: http://i.imgur.com/HxaU7F1.png But after having saved the page, and enter template edit again, I'm getting following: http://i.imgur.com/VPROUwb.png",1372596044,"PHID-USER-2mkpm2voxepwvz7abjug","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","When I make a new template entry and open the template before I've saved the page, it looks like following: http://i.imgur.com/HxaU7F1.png But after having saved the page, and enter template edit again, I'm getting following: http://i.imgur.com/VPROUwb.png","When I make a new template entry and open the template before I've saved the page, it looks like following: URL But after having saved the page, and enter template edit again, I'm getting following: URL",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-1,NA,"[""When I make a new template entry and open the template before I've saved the page, it looks like following:\nURL\n\nBut after having saved the page, and enter template edit again, I'm getting following:\nURL""]",NA,0,"When I make a new template entry and open the template before I've saved the page, it looks like following:\nURL\n\nBut after having saved the page, and enter template edit again, I'm getting following:\nURL" 4107,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,"(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?" 4107,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,"QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?" 4107,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,"What does that mean?" 4107,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,"You say it is visible for the template but not for the parameters." 4107,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,"So what is visible then?" 4107,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-ey46lj4dpzgt5ypwdhi4","task_subcomment","(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,"QUOTE\n\nDisplayed what?" 4439,"VisualEditor: Preserve ordering inside data-mw elements","Currently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major",1372028700,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_description","VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major","VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major","High",80,1372039643,NA,"resolved","True","c1",2,"True","False",-2,NA,"['VisualEditor: Preserve ordering inside data-mw elements.', ""Currently we don't and cause major headaches for Parsoid."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"VisualEditor: Preserve ordering inside data-mw elements." 4439,"VisualEditor: Preserve ordering inside data-mw elements","Currently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major",1372028700,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_description","VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major","VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major","High",80,1372039643,NA,"resolved","True","c1",2,"True","False",-2,NA,"['VisualEditor: Preserve ordering inside data-mw elements.', ""Currently we don't and cause major headaches for Parsoid."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: major" 4439,"VisualEditor: Preserve ordering inside data-mw elements","Currently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major",1372028700,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_description","VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major","VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major","High",80,1372039643,NA,"resolved","True","c1",2,"True","False",-2,NA,"['VisualEditor: Preserve ordering inside data-mw elements.', ""Currently we don't and cause major headaches for Parsoid."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"Currently we don't and cause major headaches for Parsoid." 4440,"VisualEditor: Preserve ordering inside data-mw elements","**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564509171#VE_totally_screwing_up",1373983343,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564509171#VE_totally_screwing_up","**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**ignatzmice.wiki** wrote:\n\nApparently bug 50080 is a duplicate of this bug.', 'However, that bug is still showing up: URL']",NA,0,"**ignatzmice.wiki** wrote:\n\nApparently bug 50080 is a duplicate of this bug." 4440,"VisualEditor: Preserve ordering inside data-mw elements","**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564509171#VE_totally_screwing_up",1373983343,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564509171#VE_totally_screwing_up","**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**ignatzmice.wiki** wrote:\n\nApparently bug 50080 is a duplicate of this bug.', 'However, that bug is still showing up: URL']",NA,0,"However, that bug is still showing up: URL" 4441,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50108 has been marked as a duplicate of this bug. ***",1372101714,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50108 has been marked as a duplicate of this bug. ***","*** Bug 50108 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50108 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50108 has been marked as a duplicate of this bug." 4441,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50108 has been marked as a duplicate of this bug. ***",1372101714,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50108 has been marked as a duplicate of this bug. ***","*** Bug 50108 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50108 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 4442,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50108 has been marked as a duplicate of this bug. ***",1372091701,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50108 has been marked as a duplicate of this bug. ***","*** Bug 50108 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50108 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50108 has been marked as a duplicate of this bug." 4442,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50108 has been marked as a duplicate of this bug. ***",1372091701,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50108 has been marked as a duplicate of this bug. ***","*** Bug 50108 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50108 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 4443,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50106 has been marked as a duplicate of this bug. ***",1372091672,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50106 has been marked as a duplicate of this bug. ***","*** Bug 50106 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50106 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50106 has been marked as a duplicate of this bug." 4443,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50106 has been marked as a duplicate of this bug. ***",1372091672,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50106 has been marked as a duplicate of this bug. ***","*** Bug 50106 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50106 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 4444,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50101 has been marked as a duplicate of this bug. ***",1372091521,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50101 has been marked as a duplicate of this bug. ***","*** Bug 50101 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50101 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50101 has been marked as a duplicate of this bug." 4444,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50101 has been marked as a duplicate of this bug. ***",1372091521,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50101 has been marked as a duplicate of this bug. ***","*** Bug 50101 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50101 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 4445,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50099 has been marked as a duplicate of this bug. ***",1372091385,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50099 has been marked as a duplicate of this bug. ***","*** Bug 50099 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50099 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50099 has been marked as a duplicate of this bug." 4445,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50099 has been marked as a duplicate of this bug. ***",1372091385,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50099 has been marked as a duplicate of this bug. ***","*** Bug 50099 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50099 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 4446,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50080 has been marked as a duplicate of this bug. ***",1372039230,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50080 has been marked as a duplicate of this bug. ***","*** Bug 50080 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50080 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50080 has been marked as a duplicate of this bug." 4446,"VisualEditor: Preserve ordering inside data-mw elements","*** Bug 50080 has been marked as a duplicate of this bug. ***",1372039230,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","*** Bug 50080 has been marked as a duplicate of this bug. ***","*** Bug 50080 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['*** Bug 50080 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 4447,"VisualEditor: Preserve ordering inside data-mw elements","Related URL: https://gerrit.wikimedia.org/r/70109 (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff)",1372032121,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-spoxch2h3fjmkmu6pdme","task_subcomment","Related URL: https://gerrit.wikimedia.org/r/70109 (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff)","Related URL: GERRIT_URL (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff)",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-1,NA,"['Related URL: GERRIT_URL (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff)']",NA,0,"Related URL: GERRIT_URL (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff)" 4487,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)","In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-2go6ew7f46vsl6ngyy7w","task_description","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","High",80,1409958003,NA,"resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)." 4487,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)","In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-2go6ew7f46vsl6ngyy7w","task_description","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","High",80,1409958003,NA,"resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"In IE10, any attempt to open the transclusion editor leads to a stack overflow." 4487,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)","In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-2go6ew7f46vsl6ngyy7w","task_description","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","High",80,1409958003,NA,"resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied." 4487,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)","In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-2go6ew7f46vsl6ngyy7w","task_description","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","High",80,1409958003,NA,"resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"load.php, line 305 character 273\n\nSCRIPT5: Access is denied." 4487,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)","In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-2go6ew7f46vsl6ngyy7w","task_description","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","High",80,1409958003,NA,"resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"load.php, line 305 character 273\n\nSCRIPT5: Access is denied." 4487,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)","In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-2go6ew7f46vsl6ngyy7w","task_description","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","High",80,1409958003,NA,"resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied." 4487,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)","In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-2go6ew7f46vsl6ngyy7w","task_description","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","High",80,1409958003,NA,"resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal" 4488,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)","This doesn't happen in IE10 with master.",1409958003,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-2go6ew7f46vsl6ngyy7w","task_subcomment","This doesn't happen in IE10 with master.","This doesn't happen in IE10 with master.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,61,NA,"[""This doesn't happen in IE10 with master.""]",NA,0,"This doesn't happen in IE10 with master." 5553,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph","e.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",1364923620,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-yqzsqc62wfjcfr3spvjk","task_description","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1366927098,NA,"resolved","True","c1",1,"True","False",-13,NA,"['VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph.', 'e.g.', 'inserting

c

d

into

ab

between a and b results in\n\n

a

c

d

b

\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph." 5553,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph","e.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",1364923620,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-yqzsqc62wfjcfr3spvjk","task_description","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1366927098,NA,"resolved","True","c1",1,"True","False",-13,NA,"['VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph.', 'e.g.', 'inserting

c

d

into

ab

between a and b results in\n\n

a

c

d

b

\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"e.g." 5553,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph","e.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",1364923620,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-yqzsqc62wfjcfr3spvjk","task_description","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1366927098,NA,"resolved","True","c1",1,"True","False",-13,NA,"['VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph.', 'e.g.', 'inserting

c

d

into

ab

between a and b results in\n\n

a

c

d

b

\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"inserting

c

d

into

ab

between a and b results in\n\n

a

c

d

b

\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two." 5553,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph","e.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",1364923620,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-yqzsqc62wfjcfr3spvjk","task_description","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting

c

d

into

ab

between a and b results in

a

c

d

b

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","High",80,1366927098,NA,"resolved","True","c1",1,"True","False",-13,NA,"['VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph.', 'e.g.', 'inserting

c

d

into

ab

between a and b results in\n\n

a

c

d

b

\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal" 5554,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph","NB: this bug is not restricted to paragraphs",1364923756,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-yqzsqc62wfjcfr3spvjk","task_subcomment","NB: this bug is not restricted to paragraphs","NB: this bug is not restricted to paragraphs",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-13,NA,"['NB: this bug is not restricted to paragraphs']",NA,0,"NB: this bug is not restricted to paragraphs" 5555,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph","https://gerrit.wikimedia.org/r/#/c/55791/",1364923669,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-yqzsqc62wfjcfr3spvjk","task_subcomment","https://gerrit.wikimedia.org/r/#/c/55791/","URL",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-13,NA,"['URL']",NA,0,"URL" 5761,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_description","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","High",80,1371063971,NA,"resolved","True","c1",1,"True","False",-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article." 5761,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_description","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","High",80,1371063971,NA,"resolved","True","c1",1,"True","False",-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,"Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted." 5761,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_description","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","High",80,1371063971,NA,"resolved","True","c1",1,"True","False",-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,"Showing the diff now shows the addition of ""\" 5761,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_description","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","High",80,1371063971,NA,"resolved","True","c1",1,"True","False",-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,"\" 5761,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_description","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","High",80,1371063971,NA,"resolved","True","c1",1,"True","False",-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,"\" 5761,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_description","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","High",80,1371063971,NA,"resolved","True","c1",1,"True","False",-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,""" (either above or below the {{infobox}}, doesn\" 5761,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_description","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","High",80,1371063971,NA,"resolved","True","c1",1,"True","False",-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,"Review and save" 5761,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_description","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","High",80,1371063971,NA,"resolved","True","c1",1,"True","False",-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,"\'\'\'a\'\'\'" 5762,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","This seems to be fixed already (try to reproduce on English Wikipedia).",1371063948,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_subcomment","This seems to be fixed already (try to reproduce on English Wikipedia).","This seems to be fixed already (try to reproduce on English Wikipedia).",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['This seems to be fixed already (try to reproduce on English Wikipedia).']",NA,0,"This seems to be fixed already (try to reproduce on English Wikipedia)." 5763,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","I think I know what's the reason of this problem. I will work on it next week.",1364152745,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_subcomment","I think I know what's the reason of this problem. I will work on it next week.","I think I know what's the reason of this problem. I will work on it next week.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-15,NA,"[""I think I know what's the reason of this problem."", 'I will work on it next week.']",NA,0,"I will work on it next week." 5763,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","I think I know what's the reason of this problem. I will work on it next week.",1364152745,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_subcomment","I think I know what's the reason of this problem. I will work on it next week.","I think I know what's the reason of this problem. I will work on it next week.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-15,NA,"[""I think I know what's the reason of this problem."", 'I will work on it next week.']",NA,0,"I think I know what's the reason of this problem." 5764,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","*** Bug 46506 has been marked as a duplicate of this bug. ***",1364127463,"PHID-USER-qmcrs2npimuywblubznv","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_subcomment","*** Bug 46506 has been marked as a duplicate of this bug. ***","*** Bug 46506 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-15,NA,"['*** Bug 46506 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 46506 has been marked as a duplicate of this bug." 5764,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","*** Bug 46506 has been marked as a duplicate of this bug. ***",1364127463,"PHID-USER-qmcrs2npimuywblubznv","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_subcomment","*** Bug 46506 has been marked as a duplicate of this bug. ***","*** Bug 46506 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-15,NA,"['*** Bug 46506 has been marked as a duplicate of this bug.', '***']",NA,0,"***" 5765,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article","This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term.",1357598884,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2hzsnhrqn3e44r3w5wpx","task_subcomment","This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term.","This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-25,NA,"['This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term.']",NA,0,"This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term." 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"VisualEditor: Trivial way to get a lot of errors." 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"1." 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"Go to URL and click edit\n2." 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"Select all using Ctrl-A (or Cmd-A) and press backspace\n3." 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"Press any content key (e.g." 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph." 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\" 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,");this.parent..." 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"Etc." 5913,"VisualEditor: Trivial way to get a lot of errors","1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_description","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('
');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","High",80,1353541840,NA,"resolved","True","c1",0,"True","False",-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'
\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: critical" 5914,"VisualEditor: Trivial way to get a lot of errors","Confirmed fixed, will be pushed live on Monday.",1353541840,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","Confirmed fixed, will be pushed live on Monday.","Confirmed fixed, will be pushed live on Monday.",NA,NA,NA,NA,NA,"True","c1",0,"True",NA,-32,NA,"['Confirmed fixed, will be pushed live on Monday.']",NA,0,"Confirmed fixed, will be pushed live on Monday." 5915,"VisualEditor: Trivial way to get a lot of errors","https://gerrit.wikimedia.org/r/#/c/34597/1",1353535425,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","https://gerrit.wikimedia.org/r/#/c/34597/1","URL",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['URL']",NA,0,"URL" 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"There were actually two cases, with two different root causes." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"This was fixed a while ago." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"Instead, all nodes would be removed except the last paragraph, which gets stripped." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"So after removing ""everything"", we are left with a document that only contains an empty paragraph." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one)." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations()." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"Trevor has a commit queued up that will fix this." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied." 5916,"VisualEditor: Trivial way to get a lot of errors","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage." 5917,"VisualEditor: Trivial way to get a lot of errors","After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.",1353138590,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.","After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-33,NA,"[""After deleting all the content document if completely empty (data.length = 0),\nhowever view still askes what are the annotations at offset 0 - and that's what\nfails."", 'Possible fix it to make method getAnnotationsFromOffset return empty set if\ngiven offset does not exists.']",NA,0,"Possible fix it to make method getAnnotationsFromOffset return empty set if\ngiven offset does not exists." 5917,"VisualEditor: Trivial way to get a lot of errors","After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.",1353138590,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.","After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-33,NA,"[""After deleting all the content document if completely empty (data.length = 0),\nhowever view still askes what are the annotations at offset 0 - and that's what\nfails."", 'Possible fix it to make method getAnnotationsFromOffset return empty set if\ngiven offset does not exists.']",NA,0,"After deleting all the content document if completely empty (data.length = 0),\nhowever view still askes what are the annotations at offset 0 - and that's what\nfails." 5918,"VisualEditor: Trivial way to get a lot of errors","%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%",1353138404,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%","%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-33,NA,"['%%%*** Bug 42218 has been marked as a duplicate of this bug.', '***%%%']",NA,0,"%%%*** Bug 42218 has been marked as a duplicate of this bug." 5918,"VisualEditor: Trivial way to get a lot of errors","%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%",1353138404,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-vsfkgcc5kyalos6vc4gl","task_subcomment","%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%","%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,"True","c1",0,"False",NA,-33,NA,"['%%%*** Bug 42218 has been marked as a duplicate of this bug.', '***%%%']",NA,0,"***%%%" 6124,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_description","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL","Medium",50,1382549565,NA,"resolved","True","c1",3,"False","False",12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,"Bugzilla data scanned for tech metrics must be aligned with repos scanned." 6124,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_description","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL","Medium",50,1382549565,NA,"resolved","True","c1",3,"False","False",12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,"Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid." 6124,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_description","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL","Medium",50,1382549565,NA,"resolved","True","c1",3,"False","False",12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,"A 100% match is probably impossible, but a 90% (or so) should be feasible." 6124,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_description","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL","Medium",50,1382549565,NA,"resolved","True","c1",3,"False","False",12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL" 6124,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_description","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL","Medium",50,1382549565,NA,"resolved","True","c1",3,"False","False",12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,"However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components." 6125,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time",1382560830,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project.', 'This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects.', '* Treating each component separately, just like we do with code repos.', '[1] URL']",NA,0,"(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project." 6125,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time",1382560830,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project.', 'This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects.', '* Treating each component separately, just like we do with code repos.', '[1] URL']",NA,0,"This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects." 6125,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time",1382560830,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project.', 'This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects.', '* Treating each component separately, just like we do with code repos.', '[1] URL']",NA,0,"* Treating each component separately, just like we do with code repos." 6125,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time",1382560830,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project.', 'This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects.', '* Treating each component separately, just like we do with code repos.', '[1] URL']",NA,0,"[1] URL" 6126,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Ok guys, you have the viz in: http://korma.wmflabs.org/browser/its-repos.html",1382549565,"PHID-USER-lepsd737p6wqwsowcou2","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Ok guys, you have the viz in: http://korma.wmflabs.org/browser/its-repos.html","Ok guys, you have the viz in: URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['Ok guys, you have the viz in:\n\nURL']",NA,0,"Ok guys, you have the viz in:\n\nURL" 6127,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.",1382519999,"PHID-USER-lepsd737p6wqwsowcou2","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: URL Datasets > Webstatscollector: URL Analytics > Wikimetrics URL Analytics > Wikistats URL Analytics > Limn URL Analytics > General/Unknown URL Commons App > iOS (iPhone or iPad) URL Wikipedia App URL Wiki Loves Monuments > Mobile URL Wikimedia > Continuous integration URL Wikimedia > DNS URL Wikimedia > OTRS URL Wikimedia > Bugzilla URL Wikimedia > wikibugs IRC bot URL Wikimedia > Blog URL Wikimedia > Fundraising: Misc. URL Wikimedia > Fundraising: Requirements URL Tools > code-utils URL Tools > mw-dumper URL Pywikibot > * URL MediaWiki-Vagrant > * URL Wikimedia Labs > tools URL openZIM > * URL Wikimedia > Quality Assurance URL I have checked all of them and works. So tomorrow you should have the new info.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['Great, I have programmed for adding to the report the next repos:\n\nAnalytics > Kraken: URL\nDatasets > Webstatscollector: URL\nAnalytics > Wikimetrics URL\nAnalytics > Wikistats URL\nAnalytics > Limn URL\nAnalytics > General/Unknown URL\nCommons App > iOS (iPhone or iPad) URL\nWikipedia App URL\nWiki Loves Monuments > Mobile URL\nWikimedia > Continuous integration URL\nWikimedia > DNS URL\nWikimedia > OTRS URL\nWikimedia > Bugzilla URL\nWikimedia > wikibugs IRC bot URL\nWikimedia > Blog URL\nWikimedia > Fundraising: Misc.', 'URL\nWikimedia > Fundraising: Requirements URL\nTools > code-utils URL\nTools > mw-dumper URL\nPywikibot > * URL\nMediaWiki-Vagrant > * URL\nWikimedia Labs > tools URL\nopenZIM > * URL\nWikimedia > Quality Assurance URL\n\nI have checked all of them and works.', 'So tomorrow you should have the new info.']",NA,0,"Great, I have programmed for adding to the report the next repos:\n\nAnalytics > Kraken: URL\nDatasets > Webstatscollector: URL\nAnalytics > Wikimetrics URL\nAnalytics > Wikistats URL\nAnalytics > Limn URL\nAnalytics > General/Unknown URL\nCommons App > iOS (iPhone or iPad) URL\nWikipedia App URL\nWiki Loves Monuments > Mobile URL\nWikimedia > Continuous integration URL\nWikimedia > DNS URL\nWikimedia > OTRS URL\nWikimedia > Bugzilla URL\nWikimedia > wikibugs IRC bot URL\nWikimedia > Blog URL\nWikimedia > Fundraising: Misc." 6127,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.",1382519999,"PHID-USER-lepsd737p6wqwsowcou2","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: URL Datasets > Webstatscollector: URL Analytics > Wikimetrics URL Analytics > Wikistats URL Analytics > Limn URL Analytics > General/Unknown URL Commons App > iOS (iPhone or iPad) URL Wikipedia App URL Wiki Loves Monuments > Mobile URL Wikimedia > Continuous integration URL Wikimedia > DNS URL Wikimedia > OTRS URL Wikimedia > Bugzilla URL Wikimedia > wikibugs IRC bot URL Wikimedia > Blog URL Wikimedia > Fundraising: Misc. URL Wikimedia > Fundraising: Requirements URL Tools > code-utils URL Tools > mw-dumper URL Pywikibot > * URL MediaWiki-Vagrant > * URL Wikimedia Labs > tools URL openZIM > * URL Wikimedia > Quality Assurance URL I have checked all of them and works. So tomorrow you should have the new info.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['Great, I have programmed for adding to the report the next repos:\n\nAnalytics > Kraken: URL\nDatasets > Webstatscollector: URL\nAnalytics > Wikimetrics URL\nAnalytics > Wikistats URL\nAnalytics > Limn URL\nAnalytics > General/Unknown URL\nCommons App > iOS (iPhone or iPad) URL\nWikipedia App URL\nWiki Loves Monuments > Mobile URL\nWikimedia > Continuous integration URL\nWikimedia > DNS URL\nWikimedia > OTRS URL\nWikimedia > Bugzilla URL\nWikimedia > wikibugs IRC bot URL\nWikimedia > Blog URL\nWikimedia > Fundraising: Misc.', 'URL\nWikimedia > Fundraising: Requirements URL\nTools > code-utils URL\nTools > mw-dumper URL\nPywikibot > * URL\nMediaWiki-Vagrant > * URL\nWikimedia Labs > tools URL\nopenZIM > * URL\nWikimedia > Quality Assurance URL\n\nI have checked all of them and works.', 'So tomorrow you should have the new info.']",NA,0,"URL\nWikimedia > Fundraising: Requirements URL\nTools > code-utils URL\nTools > mw-dumper URL\nPywikibot > * URL\nMediaWiki-Vagrant > * URL\nWikimedia Labs > tools URL\nopenZIM > * URL\nWikimedia > Quality Assurance URL\n\nI have checked all of them and works." 6127,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.",1382519999,"PHID-USER-lepsd737p6wqwsowcou2","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: URL Datasets > Webstatscollector: URL Analytics > Wikimetrics URL Analytics > Wikistats URL Analytics > Limn URL Analytics > General/Unknown URL Commons App > iOS (iPhone or iPad) URL Wikipedia App URL Wiki Loves Monuments > Mobile URL Wikimedia > Continuous integration URL Wikimedia > DNS URL Wikimedia > OTRS URL Wikimedia > Bugzilla URL Wikimedia > wikibugs IRC bot URL Wikimedia > Blog URL Wikimedia > Fundraising: Misc. URL Wikimedia > Fundraising: Requirements URL Tools > code-utils URL Tools > mw-dumper URL Pywikibot > * URL MediaWiki-Vagrant > * URL Wikimedia Labs > tools URL openZIM > * URL Wikimedia > Quality Assurance URL I have checked all of them and works. So tomorrow you should have the new info.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['Great, I have programmed for adding to the report the next repos:\n\nAnalytics > Kraken: URL\nDatasets > Webstatscollector: URL\nAnalytics > Wikimetrics URL\nAnalytics > Wikistats URL\nAnalytics > Limn URL\nAnalytics > General/Unknown URL\nCommons App > iOS (iPhone or iPad) URL\nWikipedia App URL\nWiki Loves Monuments > Mobile URL\nWikimedia > Continuous integration URL\nWikimedia > DNS URL\nWikimedia > OTRS URL\nWikimedia > Bugzilla URL\nWikimedia > wikibugs IRC bot URL\nWikimedia > Blog URL\nWikimedia > Fundraising: Misc.', 'URL\nWikimedia > Fundraising: Requirements URL\nTools > code-utils URL\nTools > mw-dumper URL\nPywikibot > * URL\nMediaWiki-Vagrant > * URL\nWikimedia Labs > tools URL\nopenZIM > * URL\nWikimedia > Quality Assurance URL\n\nI have checked all of them and works.', 'So tomorrow you should have the new info.']",NA,0,"So tomorrow you should have the new info." 6128,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Yes!",1382370607,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Yes!","Yes!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['Yes!']",NA,0,"Yes!" 6129,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?",1382353678,"PHID-USER-lepsd737p6wqwsowcou2","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?","Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?']",NA,0,"Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?" 6130,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",1382025323,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1.', 'I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"".', 'operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc.', ""-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo""]",NA,0,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1." 6130,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",1382025323,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1.', 'I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"".', 'operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc.', ""-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo""]",NA,0,"I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops""." 6130,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",1382025323,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1.', 'I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"".', 'operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc.', ""-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo""]",NA,0,"operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc." 6130,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",1382025323,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1.', 'I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"".', 'operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc.', ""-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo""]",NA,0,"-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo" 6131,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Andre, if you could point to the Bugzilla product/component of each project at https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects that would be perfect!",1381773164,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Andre, if you could point to the Bugzilla product/component of each project at https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects that would be perfect!","Andre, if you could point to the Bugzilla product/component of each project at URL that would be perfect!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,15,NA,"['Andre, if you could point to the Bugzilla product/component of each project at URL that would be perfect!']",NA,0,"Andre, if you could point to the Bugzilla product/component of each project at URL that would be perfect!" 6132,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)",1381764843,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)","(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)']",NA,0,"(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)" 6133,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!",1381760730,"PHID-USER-lepsd737p6wqwsowcou2","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!","Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,15,NA,"['Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community?', 'Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!']",NA,0,"Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community?" 6133,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!",1381760730,"PHID-USER-lepsd737p6wqwsowcou2","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!","Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,15,NA,"['Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community?', 'Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!']",NA,0,"Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!" 6134,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Yes Quim, we can scan only components.",1380184604,"PHID-USER-lepsd737p6wqwsowcou2","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Yes Quim, we can scan only components.","Yes Quim, we can scan only components.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,12,NA,"['Yes Quim, we can scan only components.']",NA,0,"Yes Quim, we can scan only components." 6135,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Álvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.",1379952721,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Álvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.","Álvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,12,NA,"['Álvaro, can MetricsGrimoire scan only specific components of a Bugzilla product?', ""The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.""]",NA,0,"Álvaro, can MetricsGrimoire scan only specific components of a Bugzilla product?" 6135,"Bugzilla data scanned for tech metrics must be aligned with repos scanned","Álvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.",1379952721,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-rmkl7hs2ktj4cx7nvrl4","task_subcomment","Álvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.","Álvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,12,NA,"['Álvaro, can MetricsGrimoire scan only specific components of a Bugzilla product?', ""The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.""]",NA,0,"The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"3)Click on Languages/cog, select Input and click on Enable Input tools." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"4)Click on Edit beta tab." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"4)Click on Save page button\n5)Now both the images are visible again." 6191,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_description","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","Medium",50,1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal" 6192,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","As of https://gerrit.wikimedia.org/r/#/c/264577/ in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.",1453748296,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_subcomment","As of https://gerrit.wikimedia.org/r/#/c/264577/ in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.","As of URL in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,134,NA,"['As of URL in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.']",NA,0,"As of URL in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow." 6193,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_subcomment","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"QUOTE\nQUOTE\n\nWhere exactly?" 6193,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_subcomment","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"In the ""alternative caption"" field of the ""Insert Image"" dialog?" 6193,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_subcomment","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"Some other field?" 6193,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_subcomment","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"The text of the page you edit?" 6193,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_subcomment","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field." 6193,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_subcomment","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported)." 6193,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_subcomment","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"Clarification highly welcome." 6193,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-hu7ibauxmtlo3ljy4pvq","task_subcomment","I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for लिप्यंतरण and इनस्क्रिप्ट I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"I've set my Language settings on URL to using native keyboard for Hindi input." 6275,"VisualEditor: 
 tags have leading whitespace removed","Around the time when VE started to support editing of pres we started to get dirty diffs like this:

http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387

This might either be a selser issue, or VE dirtying the DOM.

--------------------------
**Version**: unspecified
**Severity**: normal",1379007960,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-six3hr3num5ryuty64kf","task_description","VisualEditor: 
 tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this:

http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387

This might either be a selser issue, or VE dirtying the DOM.

--------------------------
**Version**: unspecified
**Severity**: normal","VisualEditor: 
 tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this:

URL

This might either be a selser issue, or VE dirtying the DOM.

--------------------------
**Version**: unspecified
**Severity**: normal","Medium",50,1379569694,NA,"resolved","True","c1",3,"True","False",10,NA,"['VisualEditor: 
 tags have leading whitespace removed.', 'Around the time when VE started to support editing of pres we started to get dirty diffs like this:\n\nURL\n\nThis might either be a selser issue, or VE dirtying the DOM.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: 
 tags have leading whitespace removed."
6275,"VisualEditor: 
 tags have leading whitespace removed","Around the time when VE started to support editing of pres we started to get dirty diffs like this:

http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387

This might either be a selser issue, or VE dirtying the DOM.

--------------------------
**Version**: unspecified
**Severity**: normal",1379007960,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-six3hr3num5ryuty64kf","task_description","VisualEditor: 
 tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this:

http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387

This might either be a selser issue, or VE dirtying the DOM.

--------------------------
**Version**: unspecified
**Severity**: normal","VisualEditor: 
 tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this:

URL

This might either be a selser issue, or VE dirtying the DOM.

--------------------------
**Version**: unspecified
**Severity**: normal","Medium",50,1379569694,NA,"resolved","True","c1",3,"True","False",10,NA,"['VisualEditor: 
 tags have leading whitespace removed.', 'Around the time when VE started to support editing of pres we started to get dirty diffs like this:\n\nURL\n\nThis might either be a selser issue, or VE dirtying the DOM.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Around the time when VE started to support editing of pres we started to get dirty diffs like this:\n\nURL\n\nThis might either be a selser issue, or VE dirtying the DOM."
6275,"VisualEditor: 
 tags have leading whitespace removed","Around the time when VE started to support editing of pres we started to get dirty diffs like this:

http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387

This might either be a selser issue, or VE dirtying the DOM.

--------------------------
**Version**: unspecified
**Severity**: normal",1379007960,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-six3hr3num5ryuty64kf","task_description","VisualEditor: 
 tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this:

http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387

This might either be a selser issue, or VE dirtying the DOM.

--------------------------
**Version**: unspecified
**Severity**: normal","VisualEditor: 
 tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this:

URL

This might either be a selser issue, or VE dirtying the DOM.

--------------------------
**Version**: unspecified
**Severity**: normal","Medium",50,1379569694,NA,"resolved","True","c1",3,"True","False",10,NA,"['VisualEditor: 
 tags have leading whitespace removed.', 'Around the time when VE started to support editing of pres we started to get dirty diffs like this:\n\nURL\n\nThis might either be a selser issue, or VE dirtying the DOM.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal"
6276,"VisualEditor: 
 tags have leading whitespace removed","*** Bug 53775 has been marked as a duplicate of this bug. ***",1379613849,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-six3hr3num5ryuty64kf","task_subcomment","*** Bug 53775 has been marked as a duplicate of this bug. ***","*** Bug 53775 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['*** Bug 53775 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 53775 has been marked as a duplicate of this bug."
6276,"VisualEditor: 
 tags have leading whitespace removed","*** Bug 53775 has been marked as a duplicate of this bug. ***",1379613849,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-six3hr3num5ryuty64kf","task_subcomment","*** Bug 53775 has been marked as a duplicate of this bug. ***","*** Bug 53775 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['*** Bug 53775 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
6277,"VisualEditor: 
 tags have leading whitespace removed","Change 84896 merged by Catrope:
Fix check for preformatted when stripping whitespace

https://gerrit.wikimedia.org/r/84896",1379545395,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-six3hr3num5ryuty64kf","task_subcomment","Change 84896 merged by Catrope:
Fix check for preformatted when stripping whitespace

https://gerrit.wikimedia.org/r/84896","Change 84896 merged by Catrope:
Fix check for preformatted when stripping whitespace

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Change 84896 merged by Catrope:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL']",NA,0,"Change 84896 merged by Catrope:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL"
6278,"VisualEditor: 
 tags have leading whitespace removed","Change 84896 had a related patch set uploaded by Catrope:
Fix check for preformatted when stripping whitespace

https://gerrit.wikimedia.org/r/84896",1379545270,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-six3hr3num5ryuty64kf","task_subcomment","Change 84896 had a related patch set uploaded by Catrope:
Fix check for preformatted when stripping whitespace

https://gerrit.wikimedia.org/r/84896","Change 84896 had a related patch set uploaded by Catrope:
Fix check for preformatted when stripping whitespace

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Change 84896 had a related patch set uploaded by Catrope:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL']",NA,0,"Change 84896 had a related patch set uploaded by Catrope:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL"
6279,"VisualEditor: 
 tags have leading whitespace removed","Change 84332 merged by jenkins-bot:
Fix check for preformatted when stripping whitespace

https://gerrit.wikimedia.org/r/84332",1379466707,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-six3hr3num5ryuty64kf","task_subcomment","Change 84332 merged by jenkins-bot:
Fix check for preformatted when stripping whitespace

https://gerrit.wikimedia.org/r/84332","Change 84332 merged by jenkins-bot:
Fix check for preformatted when stripping whitespace

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Change 84332 merged by jenkins-bot:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL']",NA,0,"Change 84332 merged by jenkins-bot:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL"
6280,"VisualEditor: 
 tags have leading whitespace removed","Change 84332 had a related patch set uploaded by Esanders:
Fix check for preformatted when stripping whitespace

https://gerrit.wikimedia.org/r/84332",1379346257,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-six3hr3num5ryuty64kf","task_subcomment","Change 84332 had a related patch set uploaded by Esanders:
Fix check for preformatted when stripping whitespace

https://gerrit.wikimedia.org/r/84332","Change 84332 had a related patch set uploaded by Esanders:
Fix check for preformatted when stripping whitespace

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Change 84332 had a related patch set uploaded by Esanders:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL']",NA,0,"Change 84332 had a related patch set uploaded by Esanders:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL"
6281,"VisualEditor: 
 tags have leading whitespace removed","There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.",1379008191,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-six3hr3num5ryuty64kf","task_subcomment","There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.","There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,10,NA,"[""There's a check tag on the edit, so VE dirtied something somewhere."", 'That may or may not explain the whole bug, but we should fix it.']",NA,0,"That may or may not explain the whole bug, but we should fix it."
6281,"VisualEditor: 
 tags have leading whitespace removed","There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.",1379008191,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-six3hr3num5ryuty64kf","task_subcomment","There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.","There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,10,NA,"[""There's a check tag on the edit, so VE dirtied something somewhere."", 'That may or may not explain the whole bug, but we should fix it.']",NA,0,"There's a check tag on the edit, so VE dirtied something somewhere."
6364,"VisualEditor: Pasting text into VE from external text processor removes newlines","System environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-3yhieue5lg5ipuzhildn","task_description","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1385505615,NA,"resolved","True","c1",3,"False","False",9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,"VisualEditor: Pasting text into VE from external text processor removes newlines."
6364,"VisualEditor: Pasting text into VE from external text processor removes newlines","System environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-3yhieue5lg5ipuzhildn","task_description","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1385505615,NA,"resolved","True","c1",3,"False","False",9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,"System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR)."
6364,"VisualEditor: Pasting text into VE from external text processor removes newlines","System environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-3yhieue5lg5ipuzhildn","task_description","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1385505615,NA,"resolved","True","c1",3,"False","False",9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,"Newline is not copied in any of the cases."
6364,"VisualEditor: Pasting text into VE from external text processor removes newlines","System environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-3yhieue5lg5ipuzhildn","task_description","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1385505615,NA,"resolved","True","c1",3,"False","False",9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,"The problem has also been tested by trying to copy-paste html text from chrome itself."
6364,"VisualEditor: Pasting text into VE from external text processor removes newlines","System environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-3yhieue5lg5ipuzhildn","task_description","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1385505615,NA,"resolved","True","c1",3,"False","False",9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,"Newline is not copied."
6364,"VisualEditor: Pasting text into VE from external text processor removes newlines","System environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-3yhieue5lg5ipuzhildn","task_description","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment:
Win7 X64
Google Chrome 29.0.1547.62 m

Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e

Expected output:
a
b
c
d
e

Actual output:
abcde

The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.

The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1385505615,NA,"resolved","True","c1",3,"False","False",9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,"--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL"
6365,"VisualEditor: Pasting text into VE from external text processor removes newlines","Change 86664 merged by jenkins-bot:
Rich paste

https://gerrit.wikimedia.org/r/86664",1385500082,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-3yhieue5lg5ipuzhildn","task_subcomment","Change 86664 merged by jenkins-bot:
Rich paste

https://gerrit.wikimedia.org/r/86664","Change 86664 merged by jenkins-bot:
Rich paste

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,21,NA,"['Change 86664 merged by jenkins-bot:\nRich paste\n\nGERRIT_URL']",NA,1,"Change 86664 merged by jenkins-bot:\nRich paste\n\nGERRIT_URL"
6366,"VisualEditor: Pasting text into VE from external text processor removes newlines","Works with gedit & chrome with the rich paste patch.",1381157678,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-3yhieue5lg5ipuzhildn","task_subcomment","Works with gedit & chrome with the rich paste patch.","Works with gedit & chrome with the rich paste patch.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Works with gedit & chrome with the rich paste patch.']",NA,1,"Works with gedit & chrome with the rich paste patch."
6367,"VisualEditor: Pasting text into VE from external text processor removes newlines","Change 86664 had a related patch set uploaded by Esanders:
Rich paste

https://gerrit.wikimedia.org/r/86664",1381157509,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-3yhieue5lg5ipuzhildn","task_subcomment","Change 86664 had a related patch set uploaded by Esanders:
Rich paste

https://gerrit.wikimedia.org/r/86664","Change 86664 had a related patch set uploaded by Esanders:
Rich paste

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,14,NA,"['Change 86664 had a related patch set uploaded by Esanders:\nRich paste\n\nGERRIT_URL']",NA,1,"Change 86664 had a related patch set uploaded by Esanders:\nRich paste\n\nGERRIT_URL"
6368,"VisualEditor: Pasting text into VE from external text processor removes newlines","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-3yhieue5lg5ipuzhildn","task_subcomment","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

URL is the copy from comment 0",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n  \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n  \\r and \\r\\n end of lines and it makes no difference."
6368,"VisualEditor: Pasting text into VE from external text processor removes newlines","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-3yhieue5lg5ipuzhildn","task_subcomment","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

URL is the copy from comment 0",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n  \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,"Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings."
6368,"VisualEditor: Pasting text into VE from external text processor removes newlines","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-3yhieue5lg5ipuzhildn","task_subcomment","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

URL is the copy from comment 0",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n  \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,"Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference."
6368,"VisualEditor: Pasting text into VE from external text processor removes newlines","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-3yhieue5lg5ipuzhildn","task_subcomment","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook

Using kwrite:
Tested with \n  \r and \r\n end of lines and it makes no difference.
Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.

Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:

a

b

c

d

e

None of it makes the slightest bit of difference.

URL is the copy from comment 0",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n  \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,"URL is the copy from comment 0"
6380,"VisualEditor: 
 not always preventing editing in VE","**Author:** `kwwilliams`

**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with 
 and 
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.

VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",1378317960,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_description","VisualEditor: 
 not always preventing editing in VE./n/n**Author:** `kwwilliams`

**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with 
 and 
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.

VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor: 
 not always preventing editing in VE./n/n**Author:** CODE

**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with 
 and 
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.

VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1403741232,NA,"declined","True","c1",3,"False","False",9,NA,"['VisualEditor: 
 not always preventing editing in VE.', '**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\'ve been protecting them by wrapping the article with 
 and 
.', 'This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.', 'VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,1,"VisualEditor: 
 not always preventing editing in VE."
6380,"VisualEditor: 
 not always preventing editing in VE","**Author:** `kwwilliams`

**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with 
 and 
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.

VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",1378317960,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_description","VisualEditor: 
 not always preventing editing in VE./n/n**Author:** `kwwilliams`

**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with 
 and 
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.

VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor: 
 not always preventing editing in VE./n/n**Author:** CODE

**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with 
 and 
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.

VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1403741232,NA,"declined","True","c1",3,"False","False",9,NA,"['VisualEditor: 
 not always preventing editing in VE.', '**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\'ve been protecting them by wrapping the article with 
 and 
.', 'This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.', 'VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,1,"**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\"
6380,"VisualEditor: 
 not always preventing editing in VE","**Author:** `kwwilliams`

**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with 
 and 
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.

VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",1378317960,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_description","VisualEditor: 
 not always preventing editing in VE./n/n**Author:** `kwwilliams`

**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with 
 and 
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.

VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor: 
 not always preventing editing in VE./n/n**Author:** CODE

**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with 
 and 
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.

VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1403741232,NA,"declined","True","c1",3,"False","False",9,NA,"['VisualEditor: 
 not always preventing editing in VE.', '**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\'ve been protecting them by wrapping the article with 
 and 
.', 'This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.', 'VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,1,"ve-ce-protectedNode"
6381,"VisualEditor: 
 not always preventing editing in VE","(In reply to This, that and the other from comment #13)
> As it stands, this is a dupe of bug 52141. I've put back the original bug
> summary; it seems to me that WONTFIX is the appropriate resolution for this
> bug.

Agreed.",1403741232,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","(In reply to This, that and the other from comment #13)
> As it stands, this is a dupe of bug 52141. I've put back the original bug
> summary; it seems to me that WONTFIX is the appropriate resolution for this
> bug.

Agreed.","(In reply to This, that and the other from comment #13)
QUOTE
QUOTE
QUOTE

Agreed.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,51,NA,"['(In reply to This, that and the other from comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nAgreed.']",NA,1,"(In reply to This, that and the other from comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nAgreed."
6382,"VisualEditor: 
 not always preventing editing in VE","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",1403416223,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,50,NA,"['As it stands, this is a dupe of bug 52141.', ""I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.""]",NA,1,"As it stands, this is a dupe of bug 52141."
6382,"VisualEditor: 
 not always preventing editing in VE","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",1403416223,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,50,NA,"['As it stands, this is a dupe of bug 52141.', ""I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.""]",NA,1,"I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug."
6383,"VisualEditor: 
 not always preventing editing in VE","James, that is bug 52141.  This bug was about a specific problem with the existing code.",1383886236,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","James, that is bug 52141.  This bug was about a specific problem with the existing code.","James, that is bug 52141.  This bug was about a specific problem with the existing code.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,18,NA,"['James, that is bug 52141.', 'This bug was about a specific problem with the existing code.']",NA,1,"James, that is bug 52141."
6383,"VisualEditor: 
 not always preventing editing in VE","James, that is bug 52141.  This bug was about a specific problem with the existing code.",1383886236,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","James, that is bug 52141.  This bug was about a specific problem with the existing code.","James, that is bug 52141.  This bug was about a specific problem with the existing code.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,18,NA,"['James, that is bug 52141.', 'This bug was about a specific problem with the existing code.']",NA,1,"This bug was about a specific problem with the existing code."
6384,"VisualEditor: 
 not always preventing editing in VE","Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.",1381342100,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.","Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.']",NA,1,"Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well."
6385,"VisualEditor: 
 not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article."
6385,"VisualEditor: 
 not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,"The toolbar is another way to override the protectedNode."
6385,"VisualEditor: 
 not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,"Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."
6385,"VisualEditor: 
 not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.  Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.  The toolbar is another way to override the protectedNode.

This template is also being used to create a 'pre' text area on
URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,"This template is also being used to create a 'pre' text area on\nURL"
6386,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified.

We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",1378671601,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified.

We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.","**kwwilliams** wrote:

Note URL , where another 26,000 articles that VE mutilates have been identified.

We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.', 'We really need to have a method to shield articles from VE.', ""It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.""]",NA,1,"**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified."
6386,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified.

We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",1378671601,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified.

We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.","**kwwilliams** wrote:

Note URL , where another 26,000 articles that VE mutilates have been identified.

We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.', 'We really need to have a method to shield articles from VE.', ""It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.""]",NA,1,"We really need to have a method to shield articles from VE."
6386,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified.

We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",1378671601,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified.

We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.","**kwwilliams** wrote:

Note URL , where another 26,000 articles that VE mutilates have been identified.

We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.', 'We really need to have a method to shield articles from VE.', ""It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.""]",NA,1,"It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations."
6387,"VisualEditor: 
 not always preventing editing in VE","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.

At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...

https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702",1378379690,"PHID-USER-o34e5i3eq4nstbvcf26w","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.

At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...

https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.

At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...

URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.', 'At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...\n\nURL']",NA,1,"I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP."
6387,"VisualEditor: 
 not always preventing editing in VE","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.

At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...

https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702",1378379690,"PHID-USER-o34e5i3eq4nstbvcf26w","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.

At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...

https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.

At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...

URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.', 'At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...\n\nURL']",NA,1,"At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...\n\nURL"
6388,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

(In reply to comment #6)
> On the wider point, it's not clear if there's an actual long-term need for a
> proper VE-prevention system (or if it's all solvable with a few quick fixes
> of
> bad wikitext), but if there is, we should build a proper one, not rely on a
> hack that might break.

What's unclear about that?

I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",1378324543,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

(In reply to comment #6)
> On the wider point, it's not clear if there's an actual long-term need for a
> proper VE-prevention system (or if it's all solvable with a few quick fixes
> of
> bad wikitext), but if there is, we should build a proper one, not rely on a
> hack that might break.

What's unclear about that?

I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.","**kwwilliams** wrote:

(In reply to comment #6)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

What's unclear about that?

I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"", 'I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.', 'As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.']",NA,1,"I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious."
6388,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

(In reply to comment #6)
> On the wider point, it's not clear if there's an actual long-term need for a
> proper VE-prevention system (or if it's all solvable with a few quick fixes
> of
> bad wikitext), but if there is, we should build a proper one, not rely on a
> hack that might break.

What's unclear about that?

I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",1378324543,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

(In reply to comment #6)
> On the wider point, it's not clear if there's an actual long-term need for a
> proper VE-prevention system (or if it's all solvable with a few quick fixes
> of
> bad wikitext), but if there is, we should build a proper one, not rely on a
> hack that might break.

What's unclear about that?

I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.","**kwwilliams** wrote:

(In reply to comment #6)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

What's unclear about that?

I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"", 'I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.', 'As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.']",NA,1,"As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages."
6388,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

(In reply to comment #6)
> On the wider point, it's not clear if there's an actual long-term need for a
> proper VE-prevention system (or if it's all solvable with a few quick fixes
> of
> bad wikitext), but if there is, we should build a proper one, not rely on a
> hack that might break.

What's unclear about that?

I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",1378324543,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

(In reply to comment #6)
> On the wider point, it's not clear if there's an actual long-term need for a
> proper VE-prevention system (or if it's all solvable with a few quick fixes
> of
> bad wikitext), but if there is, we should build a proper one, not rely on a
> hack that might break.

What's unclear about that?

I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.","**kwwilliams** wrote:

(In reply to comment #6)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

What's unclear about that?

I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"", 'I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.', 'As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.']",NA,1,"**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"
6389,"VisualEditor: 
 not always preventing editing in VE","(In reply to comment #5)
> The div has been removed, so people need to look at
> https://en.wikipedia.org/w/index.
> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632

In this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632

On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",1378323301,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","(In reply to comment #5)
> The div has been removed, so people need to look at
> https://en.wikipedia.org/w/index.
> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632

In this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632

On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.","(In reply to comment #5)
QUOTE
QUOTE
QUOTE

In this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: URL

On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\'s edit to the page fixed the duplication so the desired protection is no longer needed: URL\n\nOn the wider point, it\'s not clear if there\'s an actual long-term need for a proper VE-prevention system (or if it\'s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.']",NA,1,"(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\"
6389,"VisualEditor: 
 not always preventing editing in VE","(In reply to comment #5)
> The div has been removed, so people need to look at
> https://en.wikipedia.org/w/index.
> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632

In this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632

On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",1378323301,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","(In reply to comment #5)
> The div has been removed, so people need to look at
> https://en.wikipedia.org/w/index.
> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632

In this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632

On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.","(In reply to comment #5)
QUOTE
QUOTE
QUOTE

In this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: URL

On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\'s edit to the page fixed the duplication so the desired protection is no longer needed: URL\n\nOn the wider point, it\'s not clear if there\'s an actual long-term need for a proper VE-prevention system (or if it\'s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.']",NA,1,"s not clear if there\"
6389,"VisualEditor: 
 not always preventing editing in VE","(In reply to comment #5)
> The div has been removed, so people need to look at
> https://en.wikipedia.org/w/index.
> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632

In this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632

On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",1378323301,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","(In reply to comment #5)
> The div has been removed, so people need to look at
> https://en.wikipedia.org/w/index.
> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632

In this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632

On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.","(In reply to comment #5)
QUOTE
QUOTE
QUOTE

In this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: URL

On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the  was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\'s edit to the page fixed the duplication so the desired protection is no longer needed: URL\n\nOn the wider point, it\'s not clear if there\'s an actual long-term need for a proper VE-prevention system (or if it\'s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.']",NA,1,"s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break."
6390,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

The div has been removed, so people need to look at https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632",1378322920,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

The div has been removed, so people need to look at https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632","**kwwilliams** wrote:

The div has been removed, so people need to look at URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['**kwwilliams** wrote:\n\nThe div has been removed, so people need to look at URL']",NA,1,"**kwwilliams** wrote:\n\nThe div has been removed, so people need to look at URL"
6391,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

(In reply to comment #3)
> According to the documentation, the div is only meant to block editing to a
> section of a page (although that section can be the whole text), so adding
> text
> before is correct, likewise you should be able to add text after the /div.
It's a change from the original behaviour. I agree that it's not technically wrong.",1378321376,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

(In reply to comment #3)
> According to the documentation, the div is only meant to block editing to a
> section of a page (although that section can be the whole text), so adding
> text
> before is correct, likewise you should be able to add text after the /div.
It's a change from the original behaviour. I agree that it's not technically wrong.","**kwwilliams** wrote:

(In reply to comment #3)
QUOTE
QUOTE
QUOTE
QUOTE
It's a change from the original behaviour. I agree that it's not technically wrong.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nIt's a change from the original behaviour."", ""I agree that it's not technically wrong.""]",NA,1,"**kwwilliams** wrote:\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nIt's a change from the original behaviour."
6391,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

(In reply to comment #3)
> According to the documentation, the div is only meant to block editing to a
> section of a page (although that section can be the whole text), so adding
> text
> before is correct, likewise you should be able to add text after the /div.
It's a change from the original behaviour. I agree that it's not technically wrong.",1378321376,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

(In reply to comment #3)
> According to the documentation, the div is only meant to block editing to a
> section of a page (although that section can be the whole text), so adding
> text
> before is correct, likewise you should be able to add text after the /div.
It's a change from the original behaviour. I agree that it's not technically wrong.","**kwwilliams** wrote:

(In reply to comment #3)
QUOTE
QUOTE
QUOTE
QUOTE
It's a change from the original behaviour. I agree that it's not technically wrong.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nIt's a change from the original behaviour."", ""I agree that it's not technically wrong.""]",NA,1,"I agree that it's not technically wrong."
6392,"VisualEditor: 
 not always preventing editing in VE","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.

The editing templates within the div does sound like a bug though.

If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",1378320819,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.

The editing templates within the div does sound like a bug though.

If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.

The editing templates within the div does sound like a bug though.

If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.', 'The editing templates within the div does sound like a bug though.', ""If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.""]",NA,1,"According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div."
6392,"VisualEditor: 
 not always preventing editing in VE","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.

The editing templates within the div does sound like a bug though.

If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",1378320819,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.

The editing templates within the div does sound like a bug though.

If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.

The editing templates within the div does sound like a bug though.

If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.', 'The editing templates within the div does sound like a bug though.', ""If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.""]",NA,1,"The editing templates within the div does sound like a bug though."
6392,"VisualEditor: 
 not always preventing editing in VE","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.

The editing templates within the div does sound like a bug though.

If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",1378320819,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.

The editing templates within the div does sound like a bug though.

If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.

The editing templates within the div does sound like a bug though.

If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.', 'The editing templates within the div does sound like a bug though.', ""If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.""]",NA,1,"If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do."
6393,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

Firefox 23.0.1 on Windows 7.

To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",1378319066,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

Firefox 23.0.1 on Windows 7.

To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.","**kwwilliams** wrote:

Firefox 23.0.1 on Windows 7.

To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.', 'To be clear, we are still prevented from editing the text.', 'We are not prevented from editing templates, and we can insert text before div.']",NA,1,"**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7."
6393,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

Firefox 23.0.1 on Windows 7.

To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",1378319066,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

Firefox 23.0.1 on Windows 7.

To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.","**kwwilliams** wrote:

Firefox 23.0.1 on Windows 7.

To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.', 'To be clear, we are still prevented from editing the text.', 'We are not prevented from editing templates, and we can insert text before div.']",NA,1,"To be clear, we are still prevented from editing the text."
6393,"VisualEditor: 
 not always preventing editing in VE","**kwwilliams** wrote:

Firefox 23.0.1 on Windows 7.

To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",1378319066,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","**kwwilliams** wrote:

Firefox 23.0.1 on Windows 7.

To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.","**kwwilliams** wrote:

Firefox 23.0.1 on Windows 7.

To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.', 'To be clear, we are still prevented from editing the text.', 'We are not prevented from editing templates, and we can insert text before div.']",NA,1,"We are not prevented from editing templates, and we can insert text before div."
6394,"VisualEditor: 
 not always preventing editing in VE","The original person to report this noted that they were using Chrome 29 on Windows 7.

I have been unable to reproduce this in Firefox 23 on Linux.

Neither kww or the ip who can reproduce this have noted their system.",1378318792,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","The original person to report this noted that they were using Chrome 29 on Windows 7.

I have been unable to reproduce this in Firefox 23 on Linux.

Neither kww or the ip who can reproduce this have noted their system.","The original person to report this noted that they were using Chrome 29 on Windows 7.

I have been unable to reproduce this in Firefox 23 on Linux.

Neither kww or the ip who can reproduce this have noted their system.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['The original person to report this noted that they were using Chrome 29 on Windows 7.', 'I have been unable to reproduce this in Firefox 23 on Linux.', 'Neither kww or the ip who can reproduce this have noted their system.']",NA,1,"The original person to report this noted that they were using Chrome 29 on Windows 7."
6394,"VisualEditor: 
 not always preventing editing in VE","The original person to report this noted that they were using Chrome 29 on Windows 7.

I have been unable to reproduce this in Firefox 23 on Linux.

Neither kww or the ip who can reproduce this have noted their system.",1378318792,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","The original person to report this noted that they were using Chrome 29 on Windows 7.

I have been unable to reproduce this in Firefox 23 on Linux.

Neither kww or the ip who can reproduce this have noted their system.","The original person to report this noted that they were using Chrome 29 on Windows 7.

I have been unable to reproduce this in Firefox 23 on Linux.

Neither kww or the ip who can reproduce this have noted their system.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['The original person to report this noted that they were using Chrome 29 on Windows 7.', 'I have been unable to reproduce this in Firefox 23 on Linux.', 'Neither kww or the ip who can reproduce this have noted their system.']",NA,1,"I have been unable to reproduce this in Firefox 23 on Linux."
6394,"VisualEditor: 
 not always preventing editing in VE","The original person to report this noted that they were using Chrome 29 on Windows 7.

I have been unable to reproduce this in Firefox 23 on Linux.

Neither kww or the ip who can reproduce this have noted their system.",1378318792,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-s47345xgplfmgixnp726","task_subcomment","The original person to report this noted that they were using Chrome 29 on Windows 7.

I have been unable to reproduce this in Firefox 23 on Linux.

Neither kww or the ip who can reproduce this have noted their system.","The original person to report this noted that they were using Chrome 29 on Windows 7.

I have been unable to reproduce this in Firefox 23 on Linux.

Neither kww or the ip who can reproduce this have noted their system.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['The original person to report this noted that they were using Chrome 29 on Windows 7.', 'I have been unable to reproduce this in Firefox 23 on Linux.', 'Neither kww or the ip who can reproduce this have noted their system.']",NA,1,"Neither kww or the ip who can reproduce this have noted their system."
7036,"VisualEditor: Backspace should not delete list and line in same action","**Author:** `mcdevitd`

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_description","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd`

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","Medium",50,NA,NA,"open","True","c1",3,"False","False",5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,"VisualEditor: Backspace should not delete list and line in same action."
7036,"VisualEditor: Backspace should not delete list and line in same action","**Author:** `mcdevitd`

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_description","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd`

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","Medium",50,NA,NA,"open","True","c1",3,"False","False",5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,"**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more."
7036,"VisualEditor: Backspace should not delete list and line in same action","**Author:** `mcdevitd`

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_description","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd`

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","Medium",50,NA,NA,"open","True","c1",3,"False","False",5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,"VisualEditor will completely delete the line itself and move the text to the end of the previous line."
7036,"VisualEditor: Backspace should not delete list and line in same action","**Author:** `mcdevitd`

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_description","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd`

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE

**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","Medium",50,NA,NA,"open","True","c1",3,"False","False",5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,"This is not how OpenOffice or Word works."
7037,"VisualEditor: Backspace should not delete list and line in same action","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765676,"PHID-USER-unpoeiyj52rmcfqi5rbw","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_subcomment","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,459,NA,"['Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext).', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden —\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext)."
7037,"VisualEditor: Backspace should not delete list and line in same action","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765676,"PHID-USER-unpoeiyj52rmcfqi5rbw","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_subcomment","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,459,NA,"['Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext).', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden —\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden —\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element)."
7038,"VisualEditor: Backspace should not delete list and line in same action","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765546,"PHID-USER-unpoeiyj52rmcfqi5rbw","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_subcomment","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,459,NA,"['Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty.', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden —\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty."
7038,"VisualEditor: Backspace should not delete list and line in same action","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765546,"PHID-USER-unpoeiyj52rmcfqi5rbw","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_subcomment","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden — no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,459,NA,"['Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty.', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden —\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden —\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element)."
7039,"VisualEditor: Backspace should not delete list and line in same action","Agreed. For

| 
  1. |
  2. Foo


… backspace at the cursor position indicated should convert the document into:

| 
|
  1. Foo


… with the initial 
 being a slug.

For nested list items we should pop to the next level:

| 
  1. Foo
    1. |
    2. Foo


->


| 
  1. Foo
  2. |
    1. Foo


I think?",1394479004,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_subcomment","Agreed. For

| 
  1. |
  2. Foo


… backspace at the cursor position indicated should convert the document into:

| 
|
  1. Foo


… with the initial 
 being a slug.

For nested list items we should pop to the next level:

| 
  1. Foo
    1. |
    2. Foo


->


| 
  1. Foo
  2. |
    1. Foo


I think?","Agreed. For

| 
  1. |
  2. Foo


… backspace at the cursor position indicated should convert the document into:

| 
|
  1. Foo


… with the initial 
 being a slug.

For nested list items we should pop to the next level:

| 
  1. Foo
    1. |
    2. Foo


->


| 
  1. Foo
  2. |
    1. Foo


I think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['Agreed.', 'For\n\n| 
  1. |
  2. Foo
\n\n…\xa0backspace at the cursor position indicated should convert the document into:\n\n| 
|
  1. Foo
\n\n… with the initial 
 being a slug.', 'For nested list items we should pop to the next level:\n\n| 
  1. Foo
    1. |
    2. Foo
\n\n->\n\n\n| 
  1. Foo
  2. |
    1. Foo
\n\nI think?']",NA,1,"Agreed."
7039,"VisualEditor: Backspace should not delete list and line in same action","Agreed. For

| 
  1. |
  2. Foo


… backspace at the cursor position indicated should convert the document into:

| 
|
  1. Foo


… with the initial 
 being a slug.

For nested list items we should pop to the next level:

| 
  1. Foo
    1. |
    2. Foo


->


| 
  1. Foo
  2. |
    1. Foo


I think?",1394479004,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_subcomment","Agreed. For

| 
  1. |
  2. Foo


… backspace at the cursor position indicated should convert the document into:

| 
|
  1. Foo


… with the initial 
 being a slug.

For nested list items we should pop to the next level:

| 
  1. Foo
    1. |
    2. Foo


->


| 
  1. Foo
  2. |
    1. Foo


I think?","Agreed. For

| 
  1. |
  2. Foo


… backspace at the cursor position indicated should convert the document into:

| 
|
  1. Foo


… with the initial 
 being a slug.

For nested list items we should pop to the next level:

| 
  1. Foo
    1. |
    2. Foo


->


| 
  1. Foo
  2. |
    1. Foo


I think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['Agreed.', 'For\n\n| 
  1. |
  2. Foo
\n\n…\xa0backspace at the cursor position indicated should convert the document into:\n\n| 
|
  1. Foo
\n\n… with the initial 
 being a slug.', 'For nested list items we should pop to the next level:\n\n| 
  1. Foo
    1. |
    2. Foo
\n\n->\n\n\n| 
  1. Foo
  2. |
    1. Foo
\n\nI think?']",NA,1,"For\n\n| 
  1. |
  2. Foo
\n\n…\xa0backspace at the cursor position indicated should convert the document into:\n\n| 
|
  1. Foo
\n\n… with the initial 
 being a slug."
7039,"VisualEditor: Backspace should not delete list and line in same action","Agreed. For

| 
  1. |
  2. Foo


… backspace at the cursor position indicated should convert the document into:

| 
|
  1. Foo


… with the initial 
 being a slug.

For nested list items we should pop to the next level:

| 
  1. Foo
    1. |
    2. Foo


->


| 
  1. Foo
  2. |
    1. Foo


I think?",1394479004,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrzpbb2v2s74ml5e53ww","task_subcomment","Agreed. For

| 
  1. |
  2. Foo


… backspace at the cursor position indicated should convert the document into:

| 
|
  1. Foo


… with the initial 
 being a slug.

For nested list items we should pop to the next level:

| 
  1. Foo
    1. |
    2. Foo


->


| 
  1. Foo
  2. |
    1. Foo


I think?","Agreed. For

| 
  1. |
  2. Foo


… backspace at the cursor position indicated should convert the document into:

| 
|
  1. Foo


… with the initial 
 being a slug.

For nested list items we should pop to the next level:

| 
  1. Foo
    1. |
    2. Foo


->


| 
  1. Foo
  2. |
    1. Foo


I think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['Agreed.', 'For\n\n| 
  1. |
  2. Foo
\n\n…\xa0backspace at the cursor position indicated should convert the document into:\n\n| 
|
  1. Foo
\n\n… with the initial 
 being a slug.', 'For nested list items we should pop to the next level:\n\n| 
  1. Foo
    1. |
    2. Foo
\n\n->\n\n\n| 
  1. Foo
  2. |
    1. Foo
\n\nI think?']",NA,1,"For nested list items we should pop to the next level:\n\n| 
  1. Foo
    1. |
    2. Foo
\n\n->\n\n\n| 
  1. Foo
  2. |
    1. Foo
\n\nI think?"
7045,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1375721160,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_description","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (URL to be deployed in on hewiki.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: URL","Medium",50,1381515689,NA,"resolved","True","c1",3,"False","False",5,NA,"['Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.', 'Users are requesting VE August update (URL to be deployed in on hewiki.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",FALSE,1,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary."
7045,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1375721160,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_description","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (URL to be deployed in on hewiki.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: URL","Medium",50,1381515689,NA,"resolved","True","c1",3,"False","False",5,NA,"['Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.', 'Users are requesting VE August update (URL to be deployed in on hewiki.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",FALSE,1,"Users are requesting VE August update (URL to be deployed in on hewiki."
7045,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1375721160,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_description","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (URL to be deployed in on hewiki.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: URL","Medium",50,1381515689,NA,"resolved","True","c1",3,"False","False",5,NA,"['Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.', 'Users are requesting VE August update (URL to be deployed in on hewiki.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",FALSE,1,"--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL"
7046,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Finally done; sorry for the delay.",1381515689,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Finally done; sorry for the delay.","Finally done; sorry for the delay.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Finally done; sorry for the delay.']",NA,1,"Finally done; sorry for the delay."
7047,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Change 87645 merged by Reedy:
Switch VisualEditor to secondary status on hewiki

https://gerrit.wikimedia.org/r/87645",1381515513,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Change 87645 merged by Reedy:
Switch VisualEditor to secondary status on hewiki

https://gerrit.wikimedia.org/r/87645","Change 87645 merged by Reedy:
Switch VisualEditor to secondary status on hewiki

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,14,NA,"['Change 87645 merged by Reedy:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL']",NA,1,"Change 87645 merged by Reedy:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL"
7048,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #14)
> Change 87645 had a related patch set uploaded by Jforrester:
> Switch VisualEditor to secondary status on hewiki
> 
> https://gerrit.wikimedia.org/r/87645

Will try to schedule this soon.",1380938287,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #14)
> Change 87645 had a related patch set uploaded by Jforrester:
> Switch VisualEditor to secondary status on hewiki
> 
> https://gerrit.wikimedia.org/r/87645

Will try to schedule this soon.","(In reply to comment #14)
QUOTE
QUOTE
QUOTE
QUOTE

Will try to schedule this soon.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #14)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWill try to schedule this soon.']",NA,1,"(In reply to comment #14)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWill try to schedule this soon."
7049,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Change 87645 had a related patch set uploaded by Jforrester:
Switch VisualEditor to secondary status on hewiki

https://gerrit.wikimedia.org/r/87645",1380938237,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Change 87645 had a related patch set uploaded by Jforrester:
Switch VisualEditor to secondary status on hewiki

https://gerrit.wikimedia.org/r/87645","Change 87645 had a related patch set uploaded by Jforrester:
Switch VisualEditor to secondary status on hewiki

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Change 87645 had a related patch set uploaded by Jforrester:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL']",NA,1,"Change 87645 had a related patch set uploaded by Jforrester:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL"
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"I think that it\"
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"t come to ""a decision""."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,":-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?"
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out)."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"But I see your point."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"Not sure."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."
7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #12)
> Thanks for adding the welcome message. 
> 
> I know there are discussions regarding these changes[1], but the change of
> the tab order (Edit and Edit source) is important for he wikipedia and Erik
> isn't totally against it [only ambivalent] :)
> 
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/
> 000419.html

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

> Since VE is enabled only in the main NS and user NS, for editors who also
> edit in other namespaces, addition of the VE edit tab ""in the middle"" may
> cause confusion.

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

> For consistency the edit source option should be alway the first
> option [in order], while VE edit should be second.

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.

There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-(

QUOTE
QUOTE
QUOTE

That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point.

QUOTE
QUOTE

An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.

Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure.

In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above."
7051,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Thanks for adding the welcome message. 

I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :)

Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second.

----
[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html",1380883041,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Thanks for adding the welcome message. 

I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :)

Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second.

----
[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html","Thanks for adding the welcome message. 

I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :)

Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second.

----
[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Thanks for adding the welcome message.', 'I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\'t totally against it [only ambivalent] :)\n\nSince VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion.', 'For consistency the edit source option should be alway the first option [in order], while VE edit should be second.', '----\n[1] URL']",NA,1,"Thanks for adding the welcome message."
7051,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Thanks for adding the welcome message. 

I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :)

Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second.

----
[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html",1380883041,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Thanks for adding the welcome message. 

I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :)

Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second.

----
[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html","Thanks for adding the welcome message. 

I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :)

Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second.

----
[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Thanks for adding the welcome message.', 'I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\'t totally against it [only ambivalent] :)\n\nSince VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion.', 'For consistency the edit source option should be alway the first option [in order], while VE edit should be second.', '----\n[1] URL']",NA,1,"I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\"
7051,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Thanks for adding the welcome message. 

I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :)

Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second.

----
[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html",1380883041,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Thanks for adding the welcome message. 

I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :)

Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second.

----
[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html","Thanks for adding the welcome message. 

I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :)

Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second.

----
[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Thanks for adding the welcome message.', 'I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\'t totally against it [only ambivalent] :)\n\nSince VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion.', 'For consistency the edit source option should be alway the first option [in order], while VE edit should be second.', '----\n[1] URL']",NA,1,"in the middle"
7052,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Change 77269 merged by jenkins-bot:
Enable VisualEditor beta welcome notice for all wikis

https://gerrit.wikimedia.org/r/77269",1378927706,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Change 77269 merged by jenkins-bot:
Enable VisualEditor beta welcome notice for all wikis

https://gerrit.wikimedia.org/r/77269","Change 77269 merged by jenkins-bot:
Enable VisualEditor beta welcome notice for all wikis

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,10,NA,"['Change 77269 merged by jenkins-bot:\nEnable VisualEditor beta welcome notice for all wikis\n\nGERRIT_URL']",NA,1,"Change 77269 merged by jenkins-bot:\nEnable VisualEditor beta welcome notice for all wikis\n\nGERRIT_URL"
7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,"[Sorry for the delay in responding.]"
7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,"The beta welcome message is now queued up to go out on all wikis with the next release when available."
7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,"Sorry."
7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.]

The beta welcome message is now queued up to go out on all wikis with the next release when available.

We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,"We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."
7054,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",1378147154,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['We are now in September so enough time have passed since August change, and the community have voted for deploying the changes.', 'Please let us know when this change is planned for deployment.']",NA,1,"We are now in September so enough time have passed since August change, and the community have voted for deploying the changes."
7054,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",1378147154,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['We are now in September so enough time have passed since August change, and the community have voted for deploying the changes.', 'Please let us know when this change is planned for deployment.']",NA,1,"Please let us know when this change is planned for deployment."
7055,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","There is is large support for the change in the village pump. 

https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1377842346,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","There is is large support for the change in the village pump. 

https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","There is is large support for the change in the village pump. 

URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,8,NA,"['There is is large support for the change in the village pump.', 'URL']",NA,1,"There is is large support for the change in the village pump."
7055,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","There is is large support for the change in the village pump. 

https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1377842346,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","There is is large support for the change in the village pump. 

https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","There is is large support for the change in the village pump. 

URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,8,NA,"['There is is large support for the change in the village pump.', 'URL']",NA,1,"URL"
7056,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","All of these",1377020909,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","All of these","All of these",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,7,NA,"['All of these']",NA,1,"All of these"
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Hey,\n\nWhich of the bits of the update do you mean?"
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"1."
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"The re-ordered tabs and section edit links, so that the VE tab is second?"
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"2."
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Giving a welcome message when you open VisualEditor for the first time?"
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"3."
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?"
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"4."
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?"
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"5."
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Removing the animation on section edit links?"
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"All of these?"
7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",1376948752,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.","Hey,

Which of the bits of the update do you mean?

1. The re-ordered tabs and section edit links, so that the VE tab is second?
2. Giving a welcome message when you open VisualEditor for the first time?
3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?
4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?
5. Removing the animation on section edit links?

All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Items 4 and 5 are already done."
7058,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","is there any progress with the request?",1376848108,"PHID-USER-cfsvvgbtlqnbt2yokfjf","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","is there any progress with the request?","is there any progress with the request?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,6,NA,"['is there any progress with the request?']",NA,1,"is there any progress with the request?"
7059,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.",1375862146,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.","Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,5,NA,"['Gerrit change 77269 will handle part of this.', 'They were just waiting on translations of the messages before enabling it.']",NA,1,"Gerrit change 77269 will handle part of this."
7059,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.",1375862146,"PHID-USER-sx63fwaih5kjt7bz4u6z","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.","Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,5,NA,"['Gerrit change 77269 will handle part of this.', 'They were just waiting on translations of the messages before enabling it.']",NA,1,"They were just waiting on translations of the messages before enabling it."
7060,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","added in the url field.",1375792847,"PHID-USER-u7udgblfyop6qd5wxot6","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","added in the url field.","added in the url field.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,5,NA,"['added in the url field.']",NA,1,"added in the url field."
7061,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #0)
> Users are requesting VE August update
> (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to
> be deployed in on hewiki.

Please provide a link to these requests, if possible.",1375791382,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","(In reply to comment #0)
> Users are requesting VE August update
> (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to
> be deployed in on hewiki.

Please provide a link to these requests, if possible.","(In reply to comment #0)
QUOTE
QUOTE
QUOTE

Please provide a link to these requests, if possible.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,5,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nPlease provide a link to these requests, if possible.']",NA,1,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nPlease provide a link to these requests, if possible."
7062,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Please mark the targeted milestone when it is known. Thanks",1375721827,"PHID-USER-u7udgblfyop6qd5wxot6","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Please mark the targeted milestone when it is known. Thanks","Please mark the targeted milestone when it is known. Thanks",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,5,NA,"['Please mark the targeted milestone when it is known.', 'Thanks']",NA,1,"Please mark the targeted milestone when it is known."
7062,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Please mark the targeted milestone when it is known. Thanks",1375721827,"PHID-USER-u7udgblfyop6qd5wxot6","PHID-TASK-wvcrw2fz7zto4p5xyqav","task_subcomment","Please mark the targeted milestone when it is known. Thanks","Please mark the targeted milestone when it is known. Thanks",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,5,NA,"['Please mark the targeted milestone when it is known.', 'Thanks']",NA,1,"Thanks"
7448,"VisualEditor: Bypass browser blacklist","Could we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_description","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1381630832,NA,"resolved","True","c1",3,"False","False",2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"VisualEditor: Bypass browser blacklist."
7448,"VisualEditor: Bypass browser blacklist","Could we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_description","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1381630832,NA,"resolved","True","c1",3,"False","False",2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"Could we have a way to bypass the browser blacklist."
7448,"VisualEditor: Bypass browser blacklist","Could we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_description","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1381630832,NA,"resolved","True","c1",3,"False","False",2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"e.g."
7448,"VisualEditor: Bypass browser blacklist","Could we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_description","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1381630832,NA,"resolved","True","c1",3,"False","False",2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"1. a user preference to ignore the blacklist during initialisation, or\n2."
7448,"VisualEditor: Bypass browser blacklist","Could we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_description","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1381630832,NA,"resolved","True","c1",3,"False","False",2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers."
7448,"VisualEditor: Bypass browser blacklist","Could we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_description","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1381630832,NA,"resolved","True","c1",3,"False","False",2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that."
7448,"VisualEditor: Bypass browser blacklist","Could we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_description","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console

This will allow mere mortals to help identify bugs with unsupported browsers.

For option four, we can modify the blacklist, like so:

JS> delete mw.libs.ve.blacklist.opera;

But im not sure what to do after that.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Medium",50,1381630832,NA,"resolved","True","c1",3,"False","False",2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL"
7449,"VisualEditor: Bypass browser blacklist","The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time.
https://gerrit.wikimedia.org/r/#/c/74574/
Changing from INVALID to FIXED, but maybe it is a dup of another bug?",1381630832,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_subcomment","The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time.
https://gerrit.wikimedia.org/r/#/c/74574/
Changing from INVALID to FIXED, but maybe it is a dup of another bug?","The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time.
URL
Changing from INVALID to FIXED, but maybe it is a dup of another bug?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,14,NA,"[""The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time."", 'URL\nChanging from INVALID to FIXED, but maybe it is a dup of another bug?']",NA,0,"URL\nChanging from INVALID to FIXED, but maybe it is a dup of another bug?"
7449,"VisualEditor: Bypass browser blacklist","The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time.
https://gerrit.wikimedia.org/r/#/c/74574/
Changing from INVALID to FIXED, but maybe it is a dup of another bug?",1381630832,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_subcomment","The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time.
https://gerrit.wikimedia.org/r/#/c/74574/
Changing from INVALID to FIXED, but maybe it is a dup of another bug?","The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time.
URL
Changing from INVALID to FIXED, but maybe it is a dup of another bug?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,14,NA,"[""The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time."", 'URL\nChanging from INVALID to FIXED, but maybe it is a dup of another bug?']",NA,0,"The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time."
7450,"VisualEditor: Bypass browser blacklist","You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!",1377532459,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-iycnxhmj2yiay4bvfsic","task_subcomment","You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!","You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,8,NA,"['You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!']",NA,0,"You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!"
7451,"VisualEditor: Bypass browser blacklist","For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in 

https://bits.wikimedia.org/static-1.22wmf10/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js

Then execute
JS> delete init.blacklist.opera

And resume running the VE scripts.

Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.",1374372834,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_subcomment","For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in 

https://bits.wikimedia.org/static-1.22wmf10/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js

Then execute
JS> delete init.blacklist.opera

And resume running the VE scripts.

Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.","For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in 

URL

Then execute
JS> delete init.blacklist.opera

And resume running the VE scripts.

Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"[""For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in \n\nURL\n\nThen execute\nJS> delete init.blacklist.opera\n\nAnd resume running the VE scripts."", 'Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.']",NA,0,"Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful."
7451,"VisualEditor: Bypass browser blacklist","For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in 

https://bits.wikimedia.org/static-1.22wmf10/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js

Then execute
JS> delete init.blacklist.opera

And resume running the VE scripts.

Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.",1374372834,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-iycnxhmj2yiay4bvfsic","task_subcomment","For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in 

https://bits.wikimedia.org/static-1.22wmf10/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js

Then execute
JS> delete init.blacklist.opera

And resume running the VE scripts.

Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.","For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in 

URL

Then execute
JS> delete init.blacklist.opera

And resume running the VE scripts.

Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"[""For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in \n\nURL\n\nThen execute\nJS> delete init.blacklist.opera\n\nAnd resume running the VE scripts."", 'Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.']",NA,0,"For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in \n\nURL\n\nThen execute\nJS> delete init.blacklist.opera\n\nAnd resume running the VE scripts."
7777,"Support editing  tags to set multi-column display on/off","For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019",1373662620,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_description","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Medium",50,1505846752,"PHID-USER-kve2ug5yc3dp6ighnmqk","resolved","True","c1",3,"True","False",1,NA,"['Support editing  tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.', 'Points of agreement include:\n* The main requirements are for  to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and … another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"Support editing  tags to set multi-column display on/off."
7777,"Support editing  tags to set multi-column display on/off","For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019",1373662620,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_description","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Medium",50,1505846752,"PHID-USER-kve2ug5yc3dp6ighnmqk","resolved","True","c1",3,"True","False",1,NA,"['Support editing  tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.', 'Points of agreement include:\n* The main requirements are for  to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and … another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag."
7777,"Support editing  tags to set multi-column display on/off","For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019",1373662620,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_description","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Medium",50,1505846752,"PHID-USER-kve2ug5yc3dp6ighnmqk","resolved","True","c1",3,"True","False",1,NA,"['Support editing  tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.', 'Points of agreement include:\n* The main requirements are for  to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and … another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"Points of agreement include:\n* The main requirements are for  to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size."
7777,"Support editing  tags to set multi-column display on/off","For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019",1373662620,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_description","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Medium",50,1505846752,"PHID-USER-kve2ug5yc3dp6ighnmqk","resolved","True","c1",3,"True","False",1,NA,"['Support editing  tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.', 'Points of agreement include:\n* The main requirements are for  to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and … another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level."
7777,"Support editing  tags to set multi-column display on/off","For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019",1373662620,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_description","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Medium",50,1505846752,"PHID-USER-kve2ug5yc3dp6ighnmqk","resolved","True","c1",3,"True","False",1,NA,"['Support editing  tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.', 'Points of agreement include:\n* The main requirements are for  to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and … another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"This would involve adding:\n\n* columns (default to 1; a number between 1 and … another number?"
7777,"Support editing  tags to set multi-column display on/off","For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019",1373662620,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_description","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Medium",50,1505846752,"PHID-USER-kve2ug5yc3dp6ighnmqk","resolved","True","c1",3,"True","False",1,NA,"['Support editing  tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.', 'Points of agreement include:\n* The main requirements are for  to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and … another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy."
7777,"Support editing  tags to set multi-column display on/off","For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019",1373662620,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_description","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Medium",50,1505846752,"PHID-USER-kve2ug5yc3dp6ighnmqk","resolved","True","c1",3,"True","False",1,NA,"['Support editing  tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.', 'Points of agreement include:\n* The main requirements are for  to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and … another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"**See Also**: T53145, T8019"
7777,"Support editing  tags to set multi-column display on/off","For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019",1373662620,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_description","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Support editing  tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). 

It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.

Points of agreement include:
* The main requirements are for  to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.

This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki 
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.

This would involve adding:

* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)

Then we could just bot-substitute uses of the template, and everyone would be happy.

**See Also**: T53145, T8019","Medium",50,1505846752,"PHID-USER-kve2ug5yc3dp6ighnmqk","resolved","True","c1",3,"True","False",1,NA,"['Support editing  tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful  tag.', 'Points of agreement include:\n* The main requirements are for  to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the  tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and … another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."
7778,"Support editing  tags to set multi-column display on/off","Change 378935 merged by jenkins-bot:
[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute

[[https://gerrit.wikimedia.org/r/378935]]
",1505840824,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 378935 merged by jenkins-bot:
[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute

[[https://gerrit.wikimedia.org/r/378935]]
","Change 378935 merged by jenkins-bot:
[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute

[[GERRIT_URL]]
",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,220,NA,"[""Change 378935 merged by jenkins-bot:\n[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute\n\n[[GERRIT_URL]]""]",NA,0,"Change 378935 merged by jenkins-bot:\n[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute\n\n[[GERRIT_URL]]"
7779,"Support editing  tags to set multi-column display on/off","Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute

[[https://gerrit.wikimedia.org/r/378935]]
",1505835365,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute

[[https://gerrit.wikimedia.org/r/378935]]
","Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute

[[GERRIT_URL]]
",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,220,NA,"[""Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders):\n[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute\n\n[[GERRIT_URL]]""]",NA,0,"Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders):\n[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute\n\n[[GERRIT_URL]]"
7780,"Support editing  tags to set multi-column display on/off","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain  element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"Next step for en.wp will be to enables responsive by default for a plain  element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour)."
7780,"Support editing  tags to set multi-column display on/off","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain  element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"* there is also a rather large documentation gap, atm."
7780,"Support editing  tags to set multi-column display on/off","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain  element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"regarding new and old information."
7780,"Support editing  tags to set multi-column display on/off","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain  element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"")."
7780,"Support editing  tags to set multi-column display on/off","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain  element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"Just a thought."
7780,"Support editing  tags to set multi-column display on/off","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain  element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."
7780,"Support editing  tags to set multi-column display on/off","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain  element

This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element
# Different list item counters
# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).

This doesn't negate the fact that:
* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.
* there is also a rather large documentation gap, atm. regarding new and old information.
* ironically, it seems that the responsive attribute cannot be set/unset from VE

An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain  element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of  and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."
7781,"Support editing  tags to set multi-column display on/off",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,"PHID-USER-o7sy7j32bv4qerbqa3x5","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE

QUOTE

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,"QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."
7781,"Support editing  tags to set multi-column display on/off",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,"PHID-USER-o7sy7j32bv4qerbqa3x5","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE

QUOTE

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,"I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."
7781,"Support editing  tags to set multi-column display on/off",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,"PHID-USER-o7sy7j32bv4qerbqa3x5","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE

QUOTE

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,"This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."
7781,"Support editing  tags to set multi-column display on/off",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,"PHID-USER-o7sy7j32bv4qerbqa3x5","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE

QUOTE

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,"If that's the purpose of this bug, it's a failure when it still gets templated."
7781,"Support editing  tags to set multi-column display on/off",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,"PHID-USER-o7sy7j32bv4qerbqa3x5","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment",">For VisualEditor, we are continuously-bitten by  tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful  tag.

>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE

QUOTE

You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated.

This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful  tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,"This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template."
7782,"Support editing  tags to set multi-column display on/off","This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.",1435699557,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.","This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,104,NA,"['This was discussed at the weekly meeting on 2015-06-30.', ""We decided that it wasn't a priority for this quarter.""]",NA,0,"This was discussed at the weekly meeting on 2015-06-30."
7782,"Support editing  tags to set multi-column display on/off","This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.",1435699557,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.","This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,104,NA,"['This was discussed at the weekly meeting on 2015-06-30.', ""We decided that it wasn't a priority for this quarter.""]",NA,0,"We decided that it wasn't a priority for this quarter."
7783,"Support editing  tags to set multi-column display on/off","It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width).",1425310977,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width).","It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,87,NA,"['It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width).']",NA,0,"It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width)."
7784,"Support editing  tags to set multi-column display on/off","@thiemowmde mentions T33597",1416834442,"PHID-USER-tqvzwasywo4a7bnuwuz4","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","@thiemowmde mentions T33597","SCREEN_NAME mentions T33597",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,73,NA,"['SCREEN_NAME mentions T33597']",NA,0,"SCREEN_NAME mentions T33597"
7785,"Support editing  tags to set multi-column display on/off","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.",1416910461,"PHID-USER-u6ycqhfpa3k4yvlpxjt2","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,73,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See bug 31597 (T33597) for a much more elaborate proposal.']",NA,0,"Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said."
7785,"Support editing  tags to set multi-column display on/off","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.",1416910461,"PHID-USER-u6ycqhfpa3k4yvlpxjt2","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,73,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See bug 31597 (T33597) for a much more elaborate proposal.']",NA,0,"See bug 31597 (T33597) for a much more elaborate proposal."
7786,"Support editing  tags to set multi-column display on/off","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.",1416910421,"PHID-USER-u6ycqhfpa3k4yvlpxjt2","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,73,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See T31597 for a much more elaborate proposal.']",NA,0,"Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said."
7786,"Support editing  tags to set multi-column display on/off","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.",1416910421,"PHID-USER-u6ycqhfpa3k4yvlpxjt2","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,73,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See T31597 for a much more elaborate proposal.']",NA,0,"See T31597 for a much more elaborate proposal."
7787,"Support editing  tags to set multi-column display on/off","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.",1412760097,"PHID-USER-u6ycqhfpa3k4yvlpxjt2","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,66,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See bug 31597 for a much more elaborate proposal.']",NA,0,"Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said."
7787,"Support editing  tags to set multi-column display on/off","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.",1412760097,"PHID-USER-u6ycqhfpa3k4yvlpxjt2","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.","Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,66,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See bug 31597 for a much more elaborate proposal.']",NA,0,"See bug 31597 for a much more elaborate proposal."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"These are traditionally implemented in a CODE template on Wikipedia."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"That was by all accounts a compromise due to the limited capability they have inside a template."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"What people want is for stuff to just work."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"The number of columns should be determined by width, not hardcoded count."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"And while the latest patch uses width, it is still imho fundamentally flawed."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"Not a burden for the users."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"Based on design considerations, can make a reasonable choice for what the column width should be."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"And it can be improved as we collect more data and positively influence all readers."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"They vary by device, browser, etc."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"It will traditionally and up with authors using their personal preference for what looks right on their device."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"They don't actually want to specify it manually each time."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."
7788,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"These are traditionally implemented in a CODE template on Wikipedia."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"That was by all accounts a compromise due to the limited capability they have inside a template."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"What people want is for stuff to just work."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"The number of columns should be determined by width, not hardcoded count."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"And while the latest patch uses width, it is still imho fundamentally flawed."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Not a burden for the users."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Based on design considerations, can make a reasonable choice for what the column width should be."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"And it can be improved as we collect more data and positively influence all readers."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"They vary by device, browser, etc."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"It will traditionally and up with authors using their personal preference for what looks right on their device."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"They don't actually want to specify it manually each time."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."
7789,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `` list.

These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.

These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.


Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"These are traditionally implemented in a {{reflist}} template on Wikipedia."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"That was by all accounts a compromise due to the limited capability they have inside a template."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"What people want is for stuff to just work."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"The number of columns should be determined by width, not hardcoded count."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"And while the latest patch uses width, it is still imho fundamentally flawed."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Not a burden for the users."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Based on design considerations, can make a reasonable choice for what the column width should be."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"And it can be improved as we collect more data and positively influence all readers."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"They vary by device, browser, etc."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"It will traditionally and up with authors using their personal preference for what looks right on their device."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"They don't actually want to specify it manually each time."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."
7790,"Support editing  tags to set multi-column display on/off","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list.

These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time.

Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.

There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.

The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).

If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers.

While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device.

The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.

--

Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual  list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither."
7791,"Support editing  tags to set multi-column display on/off","See also:
Bug 31597 - generate class for references list according to the number of refs",1411551743,"PHID-USER-zqde3skdzpqiwny4dxt4","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","See also:
Bug 31597 - generate class for references list according to the number of refs","See also:
Bug 31597 - generate class for references list according to the number of refs",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,64,NA,"['See also:\nBug 31597 - generate class for references list according to the number of refs']",NA,0,"See also:\nBug 31597 - generate class for references list according to the number of refs"
7792,"Support editing  tags to set multi-column display on/off","Change 123105 abandoned by Alex Monk:
Support new column-width and list-style attributes to Cite's 

Reason:
ok done

https://gerrit.wikimedia.org/r/123105",1409791989,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 123105 abandoned by Alex Monk:
Support new column-width and list-style attributes to Cite's 

Reason:
ok done

https://gerrit.wikimedia.org/r/123105","Change 123105 abandoned by Alex Monk:
Support new column-width and list-style attributes to Cite's 

Reason:
ok done

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,61,NA,"[""Change 123105 abandoned by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nReason:\nok done\n\nGERRIT_URL""]",NA,0,"Change 123105 abandoned by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nReason:\nok done\n\nGERRIT_URL"
7793,"Support editing  tags to set multi-column display on/off","I picked up the Cite & VE parts of this again.",1409791787,"PHID-USER-x7ti5ksby4ubsabntlxa","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","I picked up the Cite & VE parts of this again.","I picked up the Cite & VE parts of this again.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,61,NA,"['I picked up the Cite & VE parts of this again.']",NA,0,"I picked up the Cite & VE parts of this again."
7794,"Support editing  tags to set multi-column display on/off","Change 123105 restored by Alex Monk:
Support new column-width and list-style attributes to Cite's 

Reason:
Restoring so I can do a rebase to get the VE patch working

https://gerrit.wikimedia.org/r/123105",1409791573,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 123105 restored by Alex Monk:
Support new column-width and list-style attributes to Cite's 

Reason:
Restoring so I can do a rebase to get the VE patch working

https://gerrit.wikimedia.org/r/123105","Change 123105 restored by Alex Monk:
Support new column-width and list-style attributes to Cite's 

Reason:
Restoring so I can do a rebase to get the VE patch working

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,61,NA,"[""Change 123105 restored by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nReason:\nRestoring so I can do a rebase to get the VE patch working\n\nGERRIT_URL""]",NA,0,"Change 123105 restored by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nReason:\nRestoring so I can do a rebase to get the VE patch working\n\nGERRIT_URL"
7795,"Support editing  tags to set multi-column display on/off","Change 123093 restored by Alex Monk:
WIP Support new column-width & list-style attributes to Cite's 

https://gerrit.wikimedia.org/r/123093",1409782437,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 123093 restored by Alex Monk:
WIP Support new column-width & list-style attributes to Cite's 

https://gerrit.wikimedia.org/r/123093","Change 123093 restored by Alex Monk:
WIP Support new column-width & list-style attributes to Cite's 

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,61,NA,"[""Change 123093 restored by Alex Monk:\nWIP Support new column-width & list-style attributes to Cite's \n\nGERRIT_URL""]",NA,0,"Change 123093 restored by Alex Monk:\nWIP Support new column-width & list-style attributes to Cite's \n\nGERRIT_URL"
7796,"Support editing  tags to set multi-column display on/off","Change 120962 restored by Alex Monk:
Support setting column-width and list-style in  tag

Reason:
Going to use classes.

https://gerrit.wikimedia.org/r/120962",1409782408,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 120962 restored by Alex Monk:
Support setting column-width and list-style in  tag

Reason:
Going to use classes.

https://gerrit.wikimedia.org/r/120962","Change 120962 restored by Alex Monk:
Support setting column-width and list-style in  tag

Reason:
Going to use classes.

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,61,NA,"['Change 120962 restored by Alex Monk:\nSupport setting column-width and list-style in  tag\n\nReason:\nGoing to use classes.', 'GERRIT_URL']",NA,0,"Change 120962 restored by Alex Monk:\nSupport setting column-width and list-style in  tag\n\nReason:\nGoing to use classes."
7796,"Support editing  tags to set multi-column display on/off","Change 120962 restored by Alex Monk:
Support setting column-width and list-style in  tag

Reason:
Going to use classes.

https://gerrit.wikimedia.org/r/120962",1409782408,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 120962 restored by Alex Monk:
Support setting column-width and list-style in  tag

Reason:
Going to use classes.

https://gerrit.wikimedia.org/r/120962","Change 120962 restored by Alex Monk:
Support setting column-width and list-style in  tag

Reason:
Going to use classes.

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,61,NA,"['Change 120962 restored by Alex Monk:\nSupport setting column-width and list-style in  tag\n\nReason:\nGoing to use classes.', 'GERRIT_URL']",NA,0,"GERRIT_URL"
7797,"Support editing  tags to set multi-column display on/off","Bug 22265 - Allow references to be listed with letters",1405984158,"PHID-USER-zqde3skdzpqiwny4dxt4","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Bug 22265 - Allow references to be listed with letters","Bug 22265 - Allow references to be listed with letters",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,55,NA,"['Bug 22265 - Allow references to be listed with letters']",NA,0,"Bug 22265 - Allow references to be listed with letters"
7798,"Support editing  tags to set multi-column display on/off","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,"No."
7798,"Support editing  tags to set multi-column display on/off","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,"We /are/ going to do this."
7798,"Support editing  tags to set multi-column display on/off","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,"Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way."
7798,"Support editing  tags to set multi-column display on/off","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,"It certainly isn\"
7798,"Support editing  tags to set multi-column display on/off","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,"UNCONFIRMED"
7799,"Support editing  tags to set multi-column display on/off","Change 123093 abandoned by Alex Monk:
WIP Support new column-width & list-style attributes to Cite's 

Reason:
Abandoning all related patch sets

https://gerrit.wikimedia.org/r/123093",1405780950,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 123093 abandoned by Alex Monk:
WIP Support new column-width & list-style attributes to Cite's 

Reason:
Abandoning all related patch sets

https://gerrit.wikimedia.org/r/123093","Change 123093 abandoned by Alex Monk:
WIP Support new column-width & list-style attributes to Cite's 

Reason:
Abandoning all related patch sets

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,54,NA,"[""Change 123093 abandoned by Alex Monk:\nWIP Support new column-width & list-style attributes to Cite's \n\nReason:\nAbandoning all related patch sets\n\nGERRIT_URL""]",NA,0,"Change 123093 abandoned by Alex Monk:\nWIP Support new column-width & list-style attributes to Cite's \n\nReason:\nAbandoning all related patch sets\n\nGERRIT_URL"
7800,"Support editing  tags to set multi-column display on/off","Change 120962 abandoned by Alex Monk:
Support setting column-width and list-style in  tag

https://gerrit.wikimedia.org/r/120962",1405780903,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 120962 abandoned by Alex Monk:
Support setting column-width and list-style in  tag

https://gerrit.wikimedia.org/r/120962","Change 120962 abandoned by Alex Monk:
Support setting column-width and list-style in  tag

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,54,NA,"['Change 120962 abandoned by Alex Monk:\nSupport setting column-width and list-style in  tag\n\nGERRIT_URL']",NA,0,"Change 120962 abandoned by Alex Monk:\nSupport setting column-width and list-style in  tag\n\nGERRIT_URL"
7801,"Support editing  tags to set multi-column display on/off","Change 123105 abandoned by Alex Monk:
Support new column-width and list-style attributes to Cite's 

https://gerrit.wikimedia.org/r/123105",1405780885,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 123105 abandoned by Alex Monk:
Support new column-width and list-style attributes to Cite's 

https://gerrit.wikimedia.org/r/123105","Change 123105 abandoned by Alex Monk:
Support new column-width and list-style attributes to Cite's 

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,54,NA,"[""Change 123105 abandoned by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nGERRIT_URL""]",NA,0,"Change 123105 abandoned by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nGERRIT_URL"
7802,"Support editing  tags to set multi-column display on/off","See https://gerrit.wikimedia.org/r/#/c/120962/ for more discussion on this.",1401486377,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","See https://gerrit.wikimedia.org/r/#/c/120962/ for more discussion on this.","See URL for more discussion on this.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,47,NA,"['See URL for more discussion on this.']",NA,0,"See URL for more discussion on this."
7803,"Support editing  tags to set multi-column display on/off","(In reply to Gabriel Wicke from comment #24)
> Is there a good reason to use magic attributes and inline styles here
> instead of CSS classes? The latter is easier to customize for different
> environments and creates less complexity in the parsers (PHP and Parsoid).
> 
> All VE needs is a list of classes to offer in a drop-down or the like.

Your assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality…",1401482644,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Gabriel Wicke from comment #24)
> Is there a good reason to use magic attributes and inline styles here
> instead of CSS classes? The latter is easier to customize for different
> environments and creates less complexity in the parsers (PHP and Parsoid).
> 
> All VE needs is a list of classes to offer in a drop-down or the like.

Your assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality…","(In reply to Gabriel Wicke from comment #24)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Your assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality…",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,47,NA,"[""(In reply to Gabriel Wicke from comment #24)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYour assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality…""]",NA,0,"(In reply to Gabriel Wicke from comment #24)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYour assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality…"
7804,"Support editing  tags to set multi-column display on/off","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).

All VE needs is a list of classes to offer in a drop-down or the like.",1396389434,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).

All VE needs is a list of classes to offer in a drop-down or the like.","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).

All VE needs is a list of classes to offer in a drop-down or the like.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,39,NA,"['Is there a good reason to use magic attributes and inline styles here instead of CSS classes?', 'The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).', 'All VE needs is a list of classes to offer in a drop-down or the like.']",NA,0,"Is there a good reason to use magic attributes and inline styles here instead of CSS classes?"
7804,"Support editing  tags to set multi-column display on/off","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).

All VE needs is a list of classes to offer in a drop-down or the like.",1396389434,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).

All VE needs is a list of classes to offer in a drop-down or the like.","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).

All VE needs is a list of classes to offer in a drop-down or the like.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,39,NA,"['Is there a good reason to use magic attributes and inline styles here instead of CSS classes?', 'The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).', 'All VE needs is a list of classes to offer in a drop-down or the like.']",NA,0,"The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid)."
7804,"Support editing  tags to set multi-column display on/off","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).

All VE needs is a list of classes to offer in a drop-down or the like.",1396389434,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).

All VE needs is a list of classes to offer in a drop-down or the like.","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).

All VE needs is a list of classes to offer in a drop-down or the like.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,39,NA,"['Is there a good reason to use magic attributes and inline styles here instead of CSS classes?', 'The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).', 'All VE needs is a list of classes to offer in a drop-down or the like.']",NA,0,"All VE needs is a list of classes to offer in a drop-down or the like."
7805,"Support editing  tags to set multi-column display on/off","Change 123105 had a related patch set uploaded by Alex Monk:
Support new column-width and list-style attributes to Cite's 

https://gerrit.wikimedia.org/r/123105",1396388659,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 123105 had a related patch set uploaded by Alex Monk:
Support new column-width and list-style attributes to Cite's 

https://gerrit.wikimedia.org/r/123105","Change 123105 had a related patch set uploaded by Alex Monk:
Support new column-width and list-style attributes to Cite's 

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,39,NA,"[""Change 123105 had a related patch set uploaded by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nGERRIT_URL""]",NA,0,"Change 123105 had a related patch set uploaded by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nGERRIT_URL"
7806,"Support editing  tags to set multi-column display on/off","Change 123093 had a related patch set uploaded by Alex Monk:
Support new column-width and list-style attributes to Cite's 

https://gerrit.wikimedia.org/r/123093",1396387228,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 123093 had a related patch set uploaded by Alex Monk:
Support new column-width and list-style attributes to Cite's 

https://gerrit.wikimedia.org/r/123093","Change 123093 had a related patch set uploaded by Alex Monk:
Support new column-width and list-style attributes to Cite's 

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,39,NA,"[""Change 123093 had a related patch set uploaded by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nGERRIT_URL""]",NA,0,"Change 123093 had a related patch set uploaded by Alex Monk:\nSupport new column-width and list-style attributes to Cite's \n\nGERRIT_URL"
7807,"Support editing  tags to set multi-column display on/off","What? We don't do LATER, and haven't for over a year.",1395858396,"PHID-USER-x7ti5ksby4ubsabntlxa","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","What? We don't do LATER, and haven't for over a year.","What? We don't do LATER, and haven't for over a year.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,38,NA,"['What?', ""We don't do LATER, and haven't for over a year.""]",NA,0,"What?"
7807,"Support editing  tags to set multi-column display on/off","What? We don't do LATER, and haven't for over a year.",1395858396,"PHID-USER-x7ti5ksby4ubsabntlxa","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","What? We don't do LATER, and haven't for over a year.","What? We don't do LATER, and haven't for over a year.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,38,NA,"['What?', ""We don't do LATER, and haven't for over a year.""]",NA,0,"We don't do LATER, and haven't for over a year."
7808,"Support editing  tags to set multi-column display on/off","IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed.",1395800703,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed.","IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,38,NA,"['IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed.']",NA,0,"IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed."
7809,"Support editing  tags to set multi-column display on/off","Change 120962 had a related patch set uploaded by Alex Monk:
Support setting column-width and list-style in  tag

https://gerrit.wikimedia.org/r/120962",1395789394,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Change 120962 had a related patch set uploaded by Alex Monk:
Support setting column-width and list-style in  tag

https://gerrit.wikimedia.org/r/120962","Change 120962 had a related patch set uploaded by Alex Monk:
Support setting column-width and list-style in  tag

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,38,NA,"['Change 120962 had a related patch set uploaded by Alex Monk:\nSupport setting column-width and list-style in  tag\n\nGERRIT_URL']",NA,0,"Change 120962 had a related patch set uploaded by Alex Monk:\nSupport setting column-width and list-style in  tag\n\nGERRIT_URL"
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width."
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL)."
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"** Make it look nice."
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,":-)\n\n** Should this default be variable as a per-wiki option?"
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal."
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"** Should this default be variable as a per-wiki/per-content-language option?"
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal."
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\"
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"t be encouraged)."
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further."
7810,"Support editing  tags to set multi-column display on/off","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",1394727173,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to Alex Monk from comment #17)
> Can someone sum up exactly what has been agreed to do here?

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?","(In reply to Alex Monk from comment #17)
QUOTE

My understanding:

Do: 

* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.

** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).

** Make it look nice. :-)

** Should this default be variable as a per-wiki option?


* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.

** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.


Do not:

* Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged).

* Add a new class to the  OL – the ""references"" class can be over-ridden locally by wikis if they want to change it further.


Is this what others think?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the  element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the  element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the  OL –\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"Is this what others think?"
7811,"Support editing  tags to set multi-column display on/off","Can someone sum up exactly what has been agreed to do here?",1394128243,"PHID-USER-x7ti5ksby4ubsabntlxa","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Can someone sum up exactly what has been agreed to do here?","Can someone sum up exactly what has been agreed to do here?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,35,NA,"['Can someone sum up exactly what has been agreed to do here?']",NA,0,"Can someone sum up exactly what has been agreed to do here?"
7812,"Support editing  tags to set multi-column display on/off","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8)
QUOTE
QUOTE

This is bug 6019.
 
QUOTE

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,"(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019."
7812,"Support editing  tags to set multi-column display on/off","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8)
QUOTE
QUOTE

This is bug 6019.
 
QUOTE

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,"QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?"
7812,"Support editing  tags to set multi-column display on/off","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8)
QUOTE
QUOTE

This is bug 6019.
 
QUOTE

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,"I am wondering whether Cite adding a class for the group name will suffice."
7812,"Support editing  tags to set multi-column display on/off","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8)
QUOTE
QUOTE

This is bug 6019.
 
QUOTE

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,"(i.e."
7812,"Support editing  tags to set multi-column display on/off","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #8)
> The references tag should support html attributes, than you can write
>  and the template can be replaced.

This is bug 6019.
 
> Needs a set up a class for list-styles.

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8)
QUOTE
QUOTE

This is bug 6019.
 
QUOTE

Has anyone done an analysis of list-style usage on the large wikis?  I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") 

I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,"emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\"
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"Multiple columns for references causes two major usability issues:\n\n1."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"2."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"This means:\na) You click the superscript number, the browser sends you to the upper part of the reference."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"b) You have to scroll down to the beginning of the reference and start reading."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"c) You have to scroll up again to the second part and continue reading."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"d) If you don\"
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"s ""back"" function, you have to scroll down again to get to the back link."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor."
7813,"Support editing  tags to set multi-column display on/off","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues:

1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.

2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means:
a) You click the superscript number, the browser sends you to the upper part of the reference.
b) You have to scroll down to the beginning of the reference and start reading.
c) You have to scroll up again to the second part and continue reading.
d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link.

Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons."
7814,"Support editing  tags to set multi-column display on/off","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",1380273005,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['For the record, both column-count and column-width are fully automated CSS properties in the browser.', ""It's 1 line of code to tell the browser, and then browsers handle it natively for us."", 'No development on our side to split the list or anything like that.']",NA,0,"For the record, both column-count and column-width are fully automated CSS properties in the browser."
7814,"Support editing  tags to set multi-column display on/off","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",1380273005,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['For the record, both column-count and column-width are fully automated CSS properties in the browser.', ""It's 1 line of code to tell the browser, and then browsers handle it natively for us."", 'No development on our side to split the list or anything like that.']",NA,0,"No development on our side to split the list or anything like that."
7814,"Support editing  tags to set multi-column display on/off","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",1380273005,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['For the record, both column-count and column-width are fully automated CSS properties in the browser.', ""It's 1 line of code to tell the browser, and then browsers handle it natively for us."", 'No development on our side to split the list or anything like that.']",NA,0,"It's 1 line of code to tell the browser, and then browsers handle it natively for us."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"When viewing it on a narrower window, it becomes unreadable."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"The result is a chaos if different column counts per article."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3)."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"Probably deriving it from the number of references in the list."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,""
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."
7815,"Support editing  tags to set multi-column display on/off","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",1380272763,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable.

column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.

The result is a chaos if different column counts per article.

When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list.

column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).

",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '']",NA,0,"Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."
7816,"Support editing  tags to set multi-column display on/off","What about the {{reflist}} variants on en.wiki such as {{notelist}}?",1377709374,"PHID-USER-zqde3skdzpqiwny4dxt4","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","What about the {{reflist}} variants on en.wiki such as {{notelist}}?","What about the {{reflist}} variants on en.wiki such as {{notelist}}?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,8,NA,"['What about the {{reflist}} variants on en.wiki such as {{notelist}}?']",NA,0,"What about the {{reflist}} variants on en.wiki such as {{notelist}}?"
7817,"Support editing  tags to set multi-column display on/off","The plwp infobox  is here:
https://pl.wikipedia.org/wiki/Szablon:Infobox_uwagi_dodaj",1373764541,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","The plwp infobox  is here:
https://pl.wikipedia.org/wiki/Szablon:Infobox_uwagi_dodaj","The plwp infobox  is here:
URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['The plwp infobox  is here:\nURL']",NA,0,"The plwp infobox  is here:\nURL"
7818,"Support editing  tags to set multi-column display on/off","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing  so people won't (often?)"", 'have to embed  in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,"have to embed  in templates."
7818,"Support editing  tags to set multi-column display on/off","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing  so people won't (often?)"", 'have to embed  in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,"The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group."
7818,"Support editing  tags to set multi-column display on/off","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing  so people won't (often?)"", 'have to embed  in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,"As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox."
7818,"Support editing  tags to set multi-column display on/off","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing  so people won't (often?)"", 'have to embed  in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,"(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing  so people won't (often?)"
7818,"Support editing  tags to set multi-column display on/off","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #7)
> I don't understand what you're saying? This is an enhancement about users
> frequently using a template to achieve a trivial software feature, and so 
> building that into reference lists (s) rather than having them
> need to invent and use the template.
> 
> Reference incidences (s) inside templates are an entirely distinct
> problem
> for VisualEditor to worry about, and this isn't about that. :-)

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

This bug seems to be about enhancing  so people won't (often?) have to embed  in templates.  However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template.  The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.  As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing  so people won't (often?)"", 'have to embed  in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,"However, I think db's point is that there are other reasons (besides {{reflist}}) that  may be in a template."
7819,"Support editing  tags to set multi-column display on/off","(In reply to comment #3)
> Also, some wikis include more stuff in their reflist-like templates; for
> example [[pl:Template:Przypisy]] unconditionally includes the heading.

Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (
, 
, ...):
https://pt.wikipedia.org/wiki/Template:Referências",1373746711,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #3)
> Also, some wikis include more stuff in their reflist-like templates; for
> example [[pl:Template:Przypisy]] unconditionally includes the heading.

Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (
, 
, ...):
https://pt.wikipedia.org/wiki/Template:Referências","(In reply to comment #3)
QUOTE
QUOTE

Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (
, 
, ...):
URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIndeed.', 'The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (
, 
, ...):\nURL']",NA,0,"(In reply to comment #3)\nQUOTE\nQUOTE\n\nIndeed."
7819,"Support editing  tags to set multi-column display on/off","(In reply to comment #3)
> Also, some wikis include more stuff in their reflist-like templates; for
> example [[pl:Template:Przypisy]] unconditionally includes the heading.

Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (
, 
, ...):
https://pt.wikipedia.org/wiki/Template:Referências",1373746711,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #3)
> Also, some wikis include more stuff in their reflist-like templates; for
> example [[pl:Template:Przypisy]] unconditionally includes the heading.

Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (
, 
, ...):
https://pt.wikipedia.org/wiki/Template:Referências","(In reply to comment #3)
QUOTE
QUOTE

Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (
, 
, ...):
URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIndeed.', 'The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (
, 
, ...):\nURL']",NA,0,"The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (
, 
, ...):\nURL"
7820,"Support editing  tags to set multi-column display on/off","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['The references tag should support html attributes, than you can write  and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,"The references tag should support html attributes, than you can write  and the template can be replaced."
7820,"Support editing  tags to set multi-column display on/off","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['The references tag should support html attributes, than you can write  and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,"Needs a set up a class for list-styles."
7820,"Support editing  tags to set multi-column display on/off","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['The references tag should support html attributes, than you can write  and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,"The extra class=""reflist"" is unneeded, because the references tag already adds class=""references""."
7820,"Support editing  tags to set multi-column display on/off","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['The references tag should support html attributes, than you can write  and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,"Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class."
7820,"Support editing  tags to set multi-column display on/off","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write  and the template can be replaced.

Needs a set up a class for list-styles.

The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".

Thats why you can already add

.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }

to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.


But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['The references tag should support html attributes, than you can write  and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,"But the template has the advanced, that syntax errors will not eat the rest of the page."
7821,"Support editing  tags to set multi-column display on/off","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",1373724517,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)","(In reply to comment #5)
QUOTE
QUOTE
QUOTE

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?"", 'This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.', ""Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that."", ':-)']",NA,0,"This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template."
7821,"Support editing  tags to set multi-column display on/off","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",1373724517,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)","(In reply to comment #5)
QUOTE
QUOTE
QUOTE

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?"", 'This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.', ""Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that."", ':-)']",NA,0,":-)"
7821,"Support editing  tags to set multi-column display on/off","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",1373724517,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)","(In reply to comment #5)
QUOTE
QUOTE
QUOTE

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?"", 'This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.', ""Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that."", ':-)']",NA,0,"(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?"
7821,"Support editing  tags to set multi-column display on/off","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",1373724517,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)","(In reply to comment #5)
QUOTE
QUOTE
QUOTE

I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.

Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?"", 'This is an enhancement about users frequently using a template to achieve a trivial software feature, and so  building that into reference lists (s) rather than having them need to invent and use the template.', ""Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that."", ':-)']",NA,0,"Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that."
7822,"Support editing  tags to set multi-column display on/off","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

Hm, yeah, I didn't think about it, but some infoboxes include their own s *and* , for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]].",1373709172,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #5)
> You will become also problems with  in infobox templates or so on, that
> means you need another soluation than add a new tag or maintain a hardcoded
> template list in VisualEditor.

Hm, yeah, I didn't think about it, but some infoboxes include their own s *and* , for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]].","(In reply to comment #5)
QUOTE
QUOTE
QUOTE

Hm, yeah, I didn't think about it, but some infoboxes include their own s *and* , for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]].",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nHm, yeah, I didn't think about it, but some infoboxes include their own s *and* , for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]].""]",NA,0,"(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nHm, yeah, I didn't think about it, but some infoboxes include their own s *and* , for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]]."
7823,"Support editing  tags to set multi-column display on/off","You will become also problems with  in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor.",1373700015,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","You will become also problems with  in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor.","You will become also problems with  in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['You will become also problems with  in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor.']",NA,0,"You will become also problems with  in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor."
7824,"Support editing  tags to set multi-column display on/off","(In reply to comment #3)
> Also, some wikis include more stuff in their reflist-like templates; for
> example [[pl:Template:Przypisy]] unconditionally includes the heading.
> 
> (In reply to comment #2)
> > > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > > browser figure out the layout makes more sense than hardcoded number
> > > (although sadly it's not how it's done right now).
> > 
> > We should be reducing, not increasing, the use of hard-coded widths. HTML is
> > not a graphical layout language, and should not be bastardised to serve as
> > such.
> 
> Hardcoding the number of columns is the same, except worse, since it can't be
> adjusted to the capabilities of the browser/device without violating CSS
> spec.
> 
> CSS only allows specifying column width ""hints"", anyway, and they can be
> measured in ems.
> https://developer.mozilla.org/en-US/docs/Web/CSS/column-width

OK, then I suppose we should maintain equivalence with {{reflist}} here.",1373665020,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #3)
> Also, some wikis include more stuff in their reflist-like templates; for
> example [[pl:Template:Przypisy]] unconditionally includes the heading.
> 
> (In reply to comment #2)
> > > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > > browser figure out the layout makes more sense than hardcoded number
> > > (although sadly it's not how it's done right now).
> > 
> > We should be reducing, not increasing, the use of hard-coded widths. HTML is
> > not a graphical layout language, and should not be bastardised to serve as
> > such.
> 
> Hardcoding the number of columns is the same, except worse, since it can't be
> adjusted to the capabilities of the browser/device without violating CSS
> spec.
> 
> CSS only allows specifying column width ""hints"", anyway, and they can be
> measured in ems.
> https://developer.mozilla.org/en-US/docs/Web/CSS/column-width

OK, then I suppose we should maintain equivalence with {{reflist}} here.","(In reply to comment #3)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

OK, then I suppose we should maintain equivalence with {{reflist}} here.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nOK, then I suppose we should maintain equivalence with {{reflist}} here.']",NA,0,"(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nOK, then I suppose we should maintain equivalence with {{reflist}} here."
7825,"Support editing  tags to set multi-column display on/off","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
> > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > browser figure out the layout makes more sense than hardcoded number (although
> > sadly it's not how it's done right now).
> 
> We should be reducing, not increasing, the use of hard-coded widths. HTML is
> not a graphical layout language, and should not be bastardised to serve as
> such.

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width",1373664227,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
> > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > browser figure out the layout makes more sense than hardcoded number (although
> > sadly it's not how it's done right now).
> 
> We should be reducing, not increasing, the use of hard-coded widths. HTML is
> not a graphical layout language, and should not be bastardised to serve as
> such.

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.', ""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec."", 'CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems.', 'URL']",NA,0,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading."
7825,"Support editing  tags to set multi-column display on/off","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
> > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > browser figure out the layout makes more sense than hardcoded number (although
> > sadly it's not how it's done right now).
> 
> We should be reducing, not increasing, the use of hard-coded widths. HTML is
> not a graphical layout language, and should not be bastardised to serve as
> such.

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width",1373664227,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
> > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > browser figure out the layout makes more sense than hardcoded number (although
> > sadly it's not how it's done right now).
> 
> We should be reducing, not increasing, the use of hard-coded widths. HTML is
> not a graphical layout language, and should not be bastardised to serve as
> such.

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.', ""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec."", 'CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems.', 'URL']",NA,0,"CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems."
7825,"Support editing  tags to set multi-column display on/off","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
> > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > browser figure out the layout makes more sense than hardcoded number (although
> > sadly it's not how it's done right now).
> 
> We should be reducing, not increasing, the use of hard-coded widths. HTML is
> not a graphical layout language, and should not be bastardised to serve as
> such.

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width",1373664227,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
> > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > browser figure out the layout makes more sense than hardcoded number (although
> > sadly it's not how it's done right now).
> 
> We should be reducing, not increasing, the use of hard-coded widths. HTML is
> not a graphical layout language, and should not be bastardised to serve as
> such.

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.', ""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec."", 'CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems.', 'URL']",NA,0,"URL"
7825,"Support editing  tags to set multi-column display on/off","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
> > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > browser figure out the layout makes more sense than hardcoded number (although
> > sadly it's not how it's done right now).
> 
> We should be reducing, not increasing, the use of hard-coded widths. HTML is
> not a graphical layout language, and should not be bastardised to serve as
> such.

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width",1373664227,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
> > ""Obviously""? In my opinion setting maximalcolumn width and letting the
> > browser figure out the layout makes more sense than hardcoded number (although
> > sadly it's not how it's done right now).
> 
> We should be reducing, not increasing, the use of hard-coded widths. HTML is
> not a graphical layout language, and should not be bastardised to serve as
> such.

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.

(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.

CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.', ""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec."", 'CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems.', 'URL']",NA,0,"(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec."
7826,"Support editing  tags to set multi-column display on/off","(In reply to comment #1)
> (In reply to comment #0)
> > * columns (default to 1; a number between 1 and … another number? - not
> > allowing width, obviously)
> 
> ""Obviously""? In my opinion setting maximalcolumn width and letting the
> browser figure out the layout makes more sense than hardcoded number (although
> sadly it's not how it's done right now).

We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such.

> > * list-style (default to decimal; just an escaped pass-through of the CSS
> > list-style of the OL)
> 
> That would be a bad way to do this; the list style should actually depends on
> the group name used (since Cite has a way to provide custom markers instead
> of [1] to reference citations, list-style is used to match them - see
> [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on
> en.wp).

Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",1373663834,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #1)
> (In reply to comment #0)
> > * columns (default to 1; a number between 1 and … another number? - not
> > allowing width, obviously)
> 
> ""Obviously""? In my opinion setting maximalcolumn width and letting the
> browser figure out the layout makes more sense than hardcoded number (although
> sadly it's not how it's done right now).

We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such.

> > * list-style (default to decimal; just an escaped pass-through of the CSS
> > list-style of the OL)
> 
> That would be a bad way to do this; the list style should actually depends on
> the group name used (since Cite has a way to provide custom markers instead
> of [1] to reference citations, list-style is used to match them - see
> [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on
> en.wp).

Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".","(In reply to comment #1)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such.

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWe should be reducing, not increasing, the use of hard-coded widths.', 'HTML is not a graphical layout language, and should not be bastardised to serve as such.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nSorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".']",NA,0,"(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWe should be reducing, not increasing, the use of hard-coded widths."
7826,"Support editing  tags to set multi-column display on/off","(In reply to comment #1)
> (In reply to comment #0)
> > * columns (default to 1; a number between 1 and … another number? - not
> > allowing width, obviously)
> 
> ""Obviously""? In my opinion setting maximalcolumn width and letting the
> browser figure out the layout makes more sense than hardcoded number (although
> sadly it's not how it's done right now).

We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such.

> > * list-style (default to decimal; just an escaped pass-through of the CSS
> > list-style of the OL)
> 
> That would be a bad way to do this; the list style should actually depends on
> the group name used (since Cite has a way to provide custom markers instead
> of [1] to reference citations, list-style is used to match them - see
> [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on
> en.wp).

Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",1373663834,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #1)
> (In reply to comment #0)
> > * columns (default to 1; a number between 1 and … another number? - not
> > allowing width, obviously)
> 
> ""Obviously""? In my opinion setting maximalcolumn width and letting the
> browser figure out the layout makes more sense than hardcoded number (although
> sadly it's not how it's done right now).

We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such.

> > * list-style (default to decimal; just an escaped pass-through of the CSS
> > list-style of the OL)
> 
> That would be a bad way to do this; the list style should actually depends on
> the group name used (since Cite has a way to provide custom markers instead
> of [1] to reference citations, list-style is used to match them - see
> [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on
> en.wp).

Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".","(In reply to comment #1)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such.

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWe should be reducing, not increasing, the use of hard-coded widths.', 'HTML is not a graphical layout language, and should not be bastardised to serve as such.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nSorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".']",NA,0,"HTML is not a graphical layout language, and should not be bastardised to serve as such."
7826,"Support editing  tags to set multi-column display on/off","(In reply to comment #1)
> (In reply to comment #0)
> > * columns (default to 1; a number between 1 and … another number? - not
> > allowing width, obviously)
> 
> ""Obviously""? In my opinion setting maximalcolumn width and letting the
> browser figure out the layout makes more sense than hardcoded number (although
> sadly it's not how it's done right now).

We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such.

> > * list-style (default to decimal; just an escaped pass-through of the CSS
> > list-style of the OL)
> 
> That would be a bad way to do this; the list style should actually depends on
> the group name used (since Cite has a way to provide custom markers instead
> of [1] to reference citations, list-style is used to match them - see
> [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on
> en.wp).

Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",1373663834,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #1)
> (In reply to comment #0)
> > * columns (default to 1; a number between 1 and … another number? - not
> > allowing width, obviously)
> 
> ""Obviously""? In my opinion setting maximalcolumn width and letting the
> browser figure out the layout makes more sense than hardcoded number (although
> sadly it's not how it's done right now).

We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such.

> > * list-style (default to decimal; just an escaped pass-through of the CSS
> > list-style of the OL)
> 
> That would be a bad way to do this; the list style should actually depends on
> the group name used (since Cite has a way to provide custom markers instead
> of [1] to reference citations, list-style is used to match them - see
> [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on
> en.wp).

Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".","(In reply to comment #1)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such.

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWe should be reducing, not increasing, the use of hard-coded widths.', 'HTML is not a graphical layout language, and should not be bastardised to serve as such.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nSorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".']",NA,0,"QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nSorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride""."
7827,"Support editing  tags to set multi-column display on/off","(In reply to comment #0)
> * columns (default to 1; a number between 1 and … another number? - not
> allowing width, obviously)

""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).


> * list-style (default to decimal; just an escaped pass-through of the CSS
> list-style of the OL)

That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",1373663426,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #0)
> * columns (default to 1; a number between 1 and … another number? - not
> allowing width, obviously)

""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).


> * list-style (default to decimal; just an escaped pass-through of the CSS
> list-style of the OL)

That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).","(In reply to comment #0)
QUOTE
QUOTE

""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).


QUOTE
QUOTE

That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\n""Obviously""?', ""In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now)."", 'QUOTE\nQUOTE\n\nThat would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).']",NA,0,"(In reply to comment #0)\nQUOTE\nQUOTE\n\n""Obviously""?"
7827,"Support editing  tags to set multi-column display on/off","(In reply to comment #0)
> * columns (default to 1; a number between 1 and … another number? - not
> allowing width, obviously)

""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).


> * list-style (default to decimal; just an escaped pass-through of the CSS
> list-style of the OL)

That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",1373663426,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #0)
> * columns (default to 1; a number between 1 and … another number? - not
> allowing width, obviously)

""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).


> * list-style (default to decimal; just an escaped pass-through of the CSS
> list-style of the OL)

That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).","(In reply to comment #0)
QUOTE
QUOTE

""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).


QUOTE
QUOTE

That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\n""Obviously""?', ""In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now)."", 'QUOTE\nQUOTE\n\nThat would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).']",NA,0,"QUOTE\nQUOTE\n\nThat would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp)."
7827,"Support editing  tags to set multi-column display on/off","(In reply to comment #0)
> * columns (default to 1; a number between 1 and … another number? - not
> allowing width, obviously)

""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).


> * list-style (default to decimal; just an escaped pass-through of the CSS
> list-style of the OL)

That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",1373663426,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-p6rccw5cwglxrbbkmq2b","task_subcomment","(In reply to comment #0)
> * columns (default to 1; a number between 1 and … another number? - not
> allowing width, obviously)

""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).


> * list-style (default to decimal; just an escaped pass-through of the CSS
> list-style of the OL)

That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).","(In reply to comment #0)
QUOTE
QUOTE

""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).


QUOTE
QUOTE

That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\n""Obviously""?', ""In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now)."", 'QUOTE\nQUOTE\n\nThat would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).']",NA,0,"In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now)."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"I fetched the Parsoid extension by using git."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure ."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"I installed that."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)"
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"And the remaining installation process are with no error."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"Debug options is uncommented."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"Others remain the same."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"That is all I have done to the whole Parsoid."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC"
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."
7882,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",1373507520,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_description","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine`

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE

**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.

 TypeError: Cannot set property '0' of null
    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)

My OS is Gentoo Linux with everything up-to-date.

I fetched the Parsoid extension by using git.

I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.

net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)

And the remaining installation process are with no error.

I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.

That is all I have done to the whole Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC","Medium",50,1373610519,NA,"declined","True","c1",3,"False","False",1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"TypeError: Cannot set property '0' of null\n    at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n    at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n    at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n    at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n    at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n    at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n    at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n    at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n    at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n    at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."
7883,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**stephdechine** wrote:

(In reply to comment #2)
> I also see that you are using Node 0.10.8.  Note that currently Parsoid only
> supports node 0.8
> (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",1373610519,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","**stephdechine** wrote:

(In reply to comment #2)
> I also see that you are using Node 0.10.8.  Note that currently Parsoid only
> supports node 0.8
> (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.","**stephdechine** wrote:

(In reply to comment #2)
QUOTE
QUOTE
QUOTE

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that.', 'After I downgrade node.js to 0.8.23 everything works correctly.', 'My fault.', 'That works for me.']",NA,0,"**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that."
7883,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**stephdechine** wrote:

(In reply to comment #2)
> I also see that you are using Node 0.10.8.  Note that currently Parsoid only
> supports node 0.8
> (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",1373610519,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","**stephdechine** wrote:

(In reply to comment #2)
> I also see that you are using Node 0.10.8.  Note that currently Parsoid only
> supports node 0.8
> (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.","**stephdechine** wrote:

(In reply to comment #2)
QUOTE
QUOTE
QUOTE

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that.', 'After I downgrade node.js to 0.8.23 everything works correctly.', 'My fault.', 'That works for me.']",NA,0,"After I downgrade node.js to 0.8.23 everything works correctly."
7883,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**stephdechine** wrote:

(In reply to comment #2)
> I also see that you are using Node 0.10.8.  Note that currently Parsoid only
> supports node 0.8
> (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",1373610519,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","**stephdechine** wrote:

(In reply to comment #2)
> I also see that you are using Node 0.10.8.  Note that currently Parsoid only
> supports node 0.8
> (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.","**stephdechine** wrote:

(In reply to comment #2)
QUOTE
QUOTE
QUOTE

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that.', 'After I downgrade node.js to 0.8.23 everything works correctly.', 'My fault.', 'That works for me.']",NA,0,"My fault."
7883,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","**stephdechine** wrote:

(In reply to comment #2)
> I also see that you are using Node 0.10.8.  Note that currently Parsoid only
> supports node 0.8
> (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",1373610519,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","**stephdechine** wrote:

(In reply to comment #2)
> I also see that you are using Node 0.10.8.  Note that currently Parsoid only
> supports node 0.8
> (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.","**stephdechine** wrote:

(In reply to comment #2)
QUOTE
QUOTE
QUOTE

Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that.', 'After I downgrade node.js to 0.8.23 everything works correctly.', 'My fault.', 'That works for me.']",NA,0,"That works for me."
7884,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","I also see that you are using Node 0.10.8.  Note that currently Parsoid only supports node 0.8 (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)",1373558667,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","I also see that you are using Node 0.10.8.  Note that currently Parsoid only supports node 0.8 (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)","I also see that you are using Node 0.10.8.  Note that currently Parsoid only supports node 0.8 (URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['I also see that you are using Node 0.10.8.', 'Note that currently Parsoid only supports node 0.8 (URL']",NA,0,"I also see that you are using Node 0.10.8."
7884,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","I also see that you are using Node 0.10.8.  Note that currently Parsoid only supports node 0.8 (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)",1373558667,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","I also see that you are using Node 0.10.8.  Note that currently Parsoid only supports node 0.8 (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10)","I also see that you are using Node 0.10.8.  Note that currently Parsoid only supports node 0.8 (URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['I also see that you are using Node 0.10.8.', 'Note that currently Parsoid only supports node 0.8 (URL']",NA,0,"Note that currently Parsoid only supports node 0.8 (URL"
7885,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.",1373556483,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['Your wiki API is not reachable from the Parsoid machine.', 'Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.', 'Example commandline:\n\ncurl \n\nWe should probably print this information when the config request fails.', 'Repurposing this bug for that.']",NA,0,"Your wiki API is not reachable from the Parsoid machine."
7885,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.",1373556483,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['Your wiki API is not reachable from the Parsoid machine.', 'Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.', 'Example commandline:\n\ncurl \n\nWe should probably print this information when the config request fails.', 'Repurposing this bug for that.']",NA,0,"Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice."
7885,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.",1373556483,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['Your wiki API is not reachable from the Parsoid machine.', 'Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.', 'Example commandline:\n\ncurl \n\nWe should probably print this information when the config request fails.', 'Repurposing this bug for that.']",NA,0,"Example commandline:\n\ncurl \n\nWe should probably print this information when the config request fails."
7885,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.",1373556483,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-l5pjiw32hngnewgrmmmy","task_subcomment","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.

Example commandline:

curl 

We should probably print this information when the config request fails. Repurposing this bug for that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['Your wiki API is not reachable from the Parsoid machine.', 'Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.', 'Example commandline:\n\ncurl \n\nWe should probably print this information when the config request fails.', 'Repurposing this bug for that.']",NA,0,"Repurposing this bug for that."
9571,"mw.hook listeners for GuidedTour for shouldSkip","Investigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement",1368612900,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-xj7stom4ugsmlhxmz6az","task_description","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","Medium",50,1402344878,NA,"resolved","True","c1",1,"True","False",-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"mw.hook listeners for GuidedTour for shouldSkip."
9571,"mw.hook listeners for GuidedTour for shouldSkip","Investigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement",1368612900,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-xj7stom4ugsmlhxmz6az","task_description","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","Medium",50,1402344878,NA,"resolved","True","c1",1,"True","False",-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"Investigate how mw.hook could be useful for GuidedTour."
9571,"mw.hook listeners for GuidedTour for shouldSkip","Investigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement",1368612900,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-xj7stom4ugsmlhxmz6az","task_description","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","Medium",50,1402344878,NA,"resolved","True","c1",1,"True","False",-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"One idea is subscribing to state changes for shouldSkip."
9571,"mw.hook listeners for GuidedTour for shouldSkip","Investigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement",1368612900,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-xj7stom4ugsmlhxmz6az","task_description","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","Medium",50,1402344878,NA,"resolved","True","c1",1,"True","False",-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages."
9571,"mw.hook listeners for GuidedTour for shouldSkip","Investigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement",1368612900,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-xj7stom4ugsmlhxmz6az","task_description","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","Medium",50,1402344878,NA,"resolved","True","c1",1,"True","False",-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this)."
9571,"mw.hook listeners for GuidedTour for shouldSkip","Investigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement",1368612900,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-xj7stom4ugsmlhxmz6az","task_description","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour.  One idea is subscribing to state changes for shouldSkip.  For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.

If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).

--------------------------
**Version**: master
**Severity**: enhancement","Medium",50,1402344878,NA,"resolved","True","c1",1,"True","False",-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"--------------------------\n**Version**: master\n**Severity**: enhancement"
9572,"mw.hook listeners for GuidedTour for shouldSkip","Change 116228 merged by jenkins-bot:
Refactor and add non-linear tours, with tests

https://gerrit.wikimedia.org/r/116228",1402332994,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-xj7stom4ugsmlhxmz6az","task_subcomment","Change 116228 merged by jenkins-bot:
Refactor and add non-linear tours, with tests

https://gerrit.wikimedia.org/r/116228","Change 116228 merged by jenkins-bot:
Refactor and add non-linear tours, with tests

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,49,NA,"['Change 116228 merged by jenkins-bot:\nRefactor and add non-linear tours, with tests\n\nGERRIT_URL']",NA,1,"Change 116228 merged by jenkins-bot:\nRefactor and add non-linear tours, with tests\n\nGERRIT_URL"
9573,"mw.hook listeners for GuidedTour for shouldSkip","Change 116228 had a related patch set uploaded by Mattflaschen:
WIP: Refactor and add non-linear tours, with tests

https://gerrit.wikimedia.org/r/116228",1397707892,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-xj7stom4ugsmlhxmz6az","task_subcomment","Change 116228 had a related patch set uploaded by Mattflaschen:
WIP: Refactor and add non-linear tours, with tests

https://gerrit.wikimedia.org/r/116228","Change 116228 had a related patch set uploaded by Mattflaschen:
WIP: Refactor and add non-linear tours, with tests

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"['Change 116228 had a related patch set uploaded by Mattflaschen:\nWIP: Refactor and add non-linear tours, with tests\n\nGERRIT_URL']",NA,1,"Change 116228 had a related patch set uploaded by Mattflaschen:\nWIP: Refactor and add non-linear tours, with tests\n\nGERRIT_URL"
9574,"mw.hook listeners for GuidedTour for shouldSkip","This is done for VisualEditor.  I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",1374693237,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-xj7stom4ugsmlhxmz6az","task_subcomment","This is done for VisualEditor.  I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.","This is done for VisualEditor.  I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"['This is done for VisualEditor.', 'I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.']",NA,1,"This is done for VisualEditor."
9574,"mw.hook listeners for GuidedTour for shouldSkip","This is done for VisualEditor.  I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",1374693237,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-xj7stom4ugsmlhxmz6az","task_subcomment","This is done for VisualEditor.  I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.","This is done for VisualEditor.  I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"['This is done for VisualEditor.', 'I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.']",NA,1,"I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard."
9575,"mw.hook listeners for GuidedTour for shouldSkip","I'm working on a change set right now that uses mw.hook for VE like this.",1373067339,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-xj7stom4ugsmlhxmz6az","task_subcomment","I'm working on a change set right now that uses mw.hook for VE like this.","I'm working on a change set right now that uses mw.hook for VE like this.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"[""I'm working on a change set right now that uses mw.hook for VE like this.""]",NA,1,"I'm working on a change set right now that uses mw.hook for VE like this."
9997,"[mediawiki.feedback.js] Feedback should follow redirect","I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1366979940,"PHID-USER-hoj4lurwi6bejyjy5qlp","PHID-TASK-xjswbfq6vvdy4oyl6qub","task_description","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Medium",50,1419984894,"PHID-USER-wkpnidxoctuhawexig5p","resolved","True","c1",1,"False","False",-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"[mediawiki.feedback.js] Feedback should follow redirect."
9997,"[mediawiki.feedback.js] Feedback should follow redirect","I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1366979940,"PHID-USER-hoj4lurwi6bejyjy5qlp","PHID-TASK-xjswbfq6vvdy4oyl6qub","task_description","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Medium",50,1419984894,"PHID-USER-wkpnidxoctuhawexig5p","resolved","True","c1",1,"False","False",-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"Is that even the correct message to change?"
9997,"[mediawiki.feedback.js] Feedback should follow redirect","I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1366979940,"PHID-USER-hoj4lurwi6bejyjy5qlp","PHID-TASK-xjswbfq6vvdy4oyl6qub","task_description","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Medium",50,1419984894,"PHID-USER-wkpnidxoctuhawexig5p","resolved","True","c1",1,"False","False",-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect."
9997,"[mediawiki.feedback.js] Feedback should follow redirect","I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1366979940,"PHID-USER-hoj4lurwi6bejyjy5qlp","PHID-TASK-xjswbfq6vvdy4oyl6qub","task_description","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Medium",50,1419984894,"PHID-USER-wkpnidxoctuhawexig5p","resolved","True","c1",1,"False","False",-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement"
9997,"[mediawiki.feedback.js] Feedback should follow redirect","I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1366979940,"PHID-USER-hoj4lurwi6bejyjy5qlp","PHID-TASK-xjswbfq6vvdy4oyl6qub","task_description","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?

I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Medium",50,1419984894,"PHID-USER-wkpnidxoctuhawexig5p","resolved","True","c1",1,"False","False",-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."
9998,"[mediawiki.feedback.js] Feedback should follow redirect","Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (https://gerrit.wikimedia.org/r/#/c/143171/).",1419984894,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-xjswbfq6vvdy4oyl6qub","task_subcomment","Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (https://gerrit.wikimedia.org/r/#/c/143171/).","Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,78,NA,"['Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (URL']",NA,0,"Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (URL"
9999,"[mediawiki.feedback.js] Feedback should follow redirect","(In reply to comment #0)
> I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't
> affect the feedback target page at all. Is that even the correct message to
> change?

Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).

[0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor
[1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor

> I then turn the target page into a redirect, but feedback are still sent to
> that page without following the redirect.

You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",1366986213,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-xjswbfq6vvdy4oyl6qub","task_subcomment","(In reply to comment #0)
> I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't
> affect the feedback target page at all. Is that even the correct message to
> change?

Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).

[0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor
[1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor

> I then turn the target page into a redirect, but feedback are still sent to
> that page without following the redirect.

You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.","(In reply to comment #0)
QUOTE
QUOTE
QUOTE

Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).

[0] - URL
[1] - URL

QUOTE
QUOTE

You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nYes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).', ""[0] - URL\n[1] - URL\n\nQUOTE\nQUOTE\n\nYou're right; this is a bug in the feedback tool, which is part of MediaWiki core."", 'Moving the bug there.']",NA,0,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nYes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated)."
9999,"[mediawiki.feedback.js] Feedback should follow redirect","(In reply to comment #0)
> I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't
> affect the feedback target page at all. Is that even the correct message to
> change?

Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).

[0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor
[1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor

> I then turn the target page into a redirect, but feedback are still sent to
> that page without following the redirect.

You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",1366986213,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-xjswbfq6vvdy4oyl6qub","task_subcomment","(In reply to comment #0)
> I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't
> affect the feedback target page at all. Is that even the correct message to
> change?

Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).

[0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor
[1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor

> I then turn the target page into a redirect, but feedback are still sent to
> that page without following the redirect.

You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.","(In reply to comment #0)
QUOTE
QUOTE
QUOTE

Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).

[0] - URL
[1] - URL

QUOTE
QUOTE

You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nYes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).', ""[0] - URL\n[1] - URL\n\nQUOTE\nQUOTE\n\nYou're right; this is a bug in the feedback tool, which is part of MediaWiki core."", 'Moving the bug there.']",NA,0,"Moving the bug there."
9999,"[mediawiki.feedback.js] Feedback should follow redirect","(In reply to comment #0)
> I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't
> affect the feedback target page at all. Is that even the correct message to
> change?

Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).

[0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor
[1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor

> I then turn the target page into a redirect, but feedback are still sent to
> that page without following the redirect.

You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",1366986213,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-xjswbfq6vvdy4oyl6qub","task_subcomment","(In reply to comment #0)
> I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't
> affect the feedback target page at all. Is that even the correct message to
> change?

Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).

[0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor
[1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor

> I then turn the target page into a redirect, but feedback are still sent to
> that page without following the redirect.

You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.","(In reply to comment #0)
QUOTE
QUOTE
QUOTE

Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).

[0] - URL
[1] - URL

QUOTE
QUOTE

You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nYes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).', ""[0] - URL\n[1] - URL\n\nQUOTE\nQUOTE\n\nYou're right; this is a bug in the feedback tool, which is part of MediaWiki core."", 'Moving the bug there.']",NA,0,"[0] - URL\n[1] - URL\n\nQUOTE\nQUOTE\n\nYou're right; this is a bug in the feedback tool, which is part of MediaWiki core."
10214,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359492240,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Medium",50,1382479475,NA,"resolved","True","c1",1,"True","False",-22,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '[Very much a longer-term enhancement.]', ""Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet)."", '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"[Very much a longer-term enhancement.]"
10214,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359492240,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Medium",50,1382479475,NA,"resolved","True","c1",1,"True","False",-22,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '[Very much a longer-term enhancement.]', ""Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet)."", '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement"
10214,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359492240,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Medium",50,1382479475,NA,"resolved","True","c1",1,"True","False",-22,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '[Very much a longer-term enhancement.]', ""Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet)."", '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)."
10214,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359492240,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.]

Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Medium",50,1382479475,NA,"resolved","True","c1",1,"True","False",-22,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '[Very much a longer-term enhancement.]', ""Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet)."", '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet)."
10215,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Change 91111 merged by jenkins-bot:
Support private wikis by forwarding Cookie: headers to Parsoid

https://gerrit.wikimedia.org/r/91111",1383678031,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Change 91111 merged by jenkins-bot:
Support private wikis by forwarding Cookie: headers to Parsoid

https://gerrit.wikimedia.org/r/91111","Change 91111 merged by jenkins-bot:
Support private wikis by forwarding Cookie: headers to Parsoid

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,18,NA,"['Change 91111 merged by jenkins-bot:\nSupport private wikis by forwarding Cookie: headers to Parsoid\n\nGERRIT_URL']",NA,0,"Change 91111 merged by jenkins-bot:\nSupport private wikis by forwarding Cookie: headers to Parsoid\n\nGERRIT_URL"
10216,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Closing again.",1382479475,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Closing again.","Closing again.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['Closing again.']",NA,0,"Closing again."
10217,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Change 91111 had a related patch set uploaded by Jforrester:
Support private wikis by forwarding Cookie: headers to Parsoid

https://gerrit.wikimedia.org/r/91111",1382404256,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Change 91111 had a related patch set uploaded by Jforrester:
Support private wikis by forwarding Cookie: headers to Parsoid

https://gerrit.wikimedia.org/r/91111","Change 91111 had a related patch set uploaded by Jforrester:
Support private wikis by forwarding Cookie: headers to Parsoid

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['Change 91111 had a related patch set uploaded by Jforrester:\nSupport private wikis by forwarding Cookie: headers to Parsoid\n\nGERRIT_URL']",NA,0,"Change 91111 had a related patch set uploaded by Jforrester:\nSupport private wikis by forwarding Cookie: headers to Parsoid\n\nGERRIT_URL"
10218,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",1381966182,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Cookies are now forwarded, and caching is disabled if a cookie is set.', 'Closing this bug as fixed.', 'A content API will have to do its own auth.']",NA,0,"Cookies are now forwarded, and caching is disabled if a cookie is set."
10218,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",1381966182,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Cookies are now forwarded, and caching is disabled if a cookie is set.', 'Closing this bug as fixed.', 'A content API will have to do its own auth.']",NA,0,"Closing this bug as fixed."
10218,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",1381966182,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Cookies are now forwarded, and caching is disabled if a cookie is set.', 'Closing this bug as fixed.', 'A content API will have to do its own auth.']",NA,0,"A content API will have to do its own auth."
10219,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Change 85414 merged by jenkins-bot:
Bug 44483: Forward Cookie header to API

https://gerrit.wikimedia.org/r/85414",1381965890,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Change 85414 merged by jenkins-bot:
Bug 44483: Forward Cookie header to API

https://gerrit.wikimedia.org/r/85414","Change 85414 merged by jenkins-bot:
Bug 44483: Forward Cookie header to API

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,15,NA,"['Change 85414 merged by jenkins-bot:\nBug 44483: Forward Cookie header to API\n\nGERRIT_URL']",NA,0,"Change 85414 merged by jenkins-bot:\nBug 44483: Forward Cookie header to API\n\nGERRIT_URL"
10220,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","(In reply to comment #4)
> Random idea:
> 
> Could Parsoid be made private (already is, though last I checked it still
> has a
> public IP) and use an internal API instead of the public API. Then the
> responsibility for user rights lays in MediaWiki land, and when the request
> is
> in Parsoid we can assume it is authenticated and thus Parsoid can have
> unrestricted access.

That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.",1381260438,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","(In reply to comment #4)
> Random idea:
> 
> Could Parsoid be made private (already is, though last I checked it still
> has a
> public IP) and use an internal API instead of the public API. Then the
> responsibility for user rights lays in MediaWiki land, and when the request
> is
> in Parsoid we can assume it is authenticated and thus Parsoid can have
> unrestricted access.

That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.","(In reply to comment #4)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See URL for the current WIP on that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"[""(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is what we'll have to do in the longer term once we store HTML."", 'Parsoid might not even be involved in that case, only the content API / storage is.', 'See URL for the current WIP on that.']",NA,0,"Parsoid might not even be involved in that case, only the content API / storage is."
10220,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","(In reply to comment #4)
> Random idea:
> 
> Could Parsoid be made private (already is, though last I checked it still
> has a
> public IP) and use an internal API instead of the public API. Then the
> responsibility for user rights lays in MediaWiki land, and when the request
> is
> in Parsoid we can assume it is authenticated and thus Parsoid can have
> unrestricted access.

That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.",1381260438,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","(In reply to comment #4)
> Random idea:
> 
> Could Parsoid be made private (already is, though last I checked it still
> has a
> public IP) and use an internal API instead of the public API. Then the
> responsibility for user rights lays in MediaWiki land, and when the request
> is
> in Parsoid we can assume it is authenticated and thus Parsoid can have
> unrestricted access.

That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.","(In reply to comment #4)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See URL for the current WIP on that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"[""(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is what we'll have to do in the longer term once we store HTML."", 'Parsoid might not even be involved in that case, only the content API / storage is.', 'See URL for the current WIP on that.']",NA,0,"See URL for the current WIP on that."
10220,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","(In reply to comment #4)
> Random idea:
> 
> Could Parsoid be made private (already is, though last I checked it still
> has a
> public IP) and use an internal API instead of the public API. Then the
> responsibility for user rights lays in MediaWiki land, and when the request
> is
> in Parsoid we can assume it is authenticated and thus Parsoid can have
> unrestricted access.

That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.",1381260438,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","(In reply to comment #4)
> Random idea:
> 
> Could Parsoid be made private (already is, though last I checked it still
> has a
> public IP) and use an internal API instead of the public API. Then the
> responsibility for user rights lays in MediaWiki land, and when the request
> is
> in Parsoid we can assume it is authenticated and thus Parsoid can have
> unrestricted access.

That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.","(In reply to comment #4)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See URL for the current WIP on that.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"[""(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is what we'll have to do in the longer term once we store HTML."", 'Parsoid might not even be involved in that case, only the content API / storage is.', 'See URL for the current WIP on that.']",NA,0,"(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is what we'll have to do in the longer term once we store HTML."
10221,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Random idea:

Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.",1380024239,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Random idea:

Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.","Random idea:

Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['Random idea:\n\nCould Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API.', 'Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.']",NA,0,"Random idea:\n\nCould Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API."
10221,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Random idea:

Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.",1380024239,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Random idea:

Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.","Random idea:

Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['Random idea:\n\nCould Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API.', 'Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.']",NA,0,"Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access."
10222,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Change 85414 had a related patch set uploaded by GWicke:
WIP Bug 44483: Forward Cookie header to API

https://gerrit.wikimedia.org/r/85414",1379754726,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Change 85414 had a related patch set uploaded by GWicke:
WIP Bug 44483: Forward Cookie header to API

https://gerrit.wikimedia.org/r/85414","Change 85414 had a related patch set uploaded by GWicke:
WIP Bug 44483: Forward Cookie header to API

GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Change 85414 had a related patch set uploaded by GWicke:\nWIP Bug 44483: Forward Cookie header to API\n\nGERRIT_URL']",NA,0,"Change 85414 had a related patch set uploaded by GWicke:\nWIP Bug 44483: Forward Cookie header to API\n\nGERRIT_URL"
10223,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","*** Bug 44313 has been marked as a duplicate of this bug. ***",1360207511,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","*** Bug 44313 has been marked as a duplicate of this bug. ***","*** Bug 44313 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-21,NA,"['*** Bug 44313 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 44313 has been marked as a duplicate of this bug."
10223,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","*** Bug 44313 has been marked as a duplicate of this bug. ***",1360207511,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","*** Bug 44313 has been marked as a duplicate of this bug. ***","*** Bug 44313 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-21,NA,"['*** Bug 44313 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
10224,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.",1359588905,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.","Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-22,NA,"['Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this.', 'Definitely worth a try.']",NA,0,"Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this."
10224,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.",1359588905,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-yycd32q4sp6a3jbmgdq4","task_subcomment","Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.","Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-22,NA,"['Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this.', 'Definitely worth a try.']",NA,0,"Definitely worth a try."
11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1374077880,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-qh3lrsa2vheyfhks3klm","task_description","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,1385386552,NA,"declined","True","c1",3,"False","False",2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source""."
11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1374077880,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-qh3lrsa2vheyfhks3klm","task_description","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,1385386552,NA,"declined","True","c1",3,"False","False",2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"When viewing an article you don\"
11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1374077880,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-qh3lrsa2vheyfhks3klm","task_description","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,1385386552,NA,"declined","True","c1",3,"False","False",2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."
11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1374077880,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-qh3lrsa2vheyfhks3klm","task_description","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,1385386552,NA,"declined","True","c1",3,"False","False",2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"view source"
11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1374077880,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-qh3lrsa2vheyfhks3klm","task_description","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,1385386552,NA,"declined","True","c1",3,"False","False",2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"view source"
11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement",1374077880,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-qh3lrsa2vheyfhks3klm","task_description","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,1385386552,NA,"declined","True","c1",3,"False","False",2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for  and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"view visual source"
11322,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",1427495377,"PHID-USER-hphmqcx66p6d6gvmjzp7","PHID-TASK-qh3lrsa2vheyfhks3klm","task_subcomment","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,90,NA,"['Comment...', 'I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles.', 'However, I do grok the additional layers of complexity this would entail...']",NA,0,"Comment..."
11322,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",1427495377,"PHID-USER-hphmqcx66p6d6gvmjzp7","PHID-TASK-qh3lrsa2vheyfhks3klm","task_subcomment","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,90,NA,"['Comment...', 'I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles.', 'However, I do grok the additional layers of complexity this would entail...']",NA,0,"I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles."
11322,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",1427495377,"PHID-USER-hphmqcx66p6d6gvmjzp7","PHID-TASK-qh3lrsa2vheyfhks3klm","task_subcomment","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,90,NA,"['Comment...', 'I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles.', 'However, I do grok the additional layers of complexity this would entail...']",NA,0,"However, I do grok the additional layers of complexity this would entail..."
11323,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","A ""read-only editor"" is the view mode… I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).",1385386552,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-qh3lrsa2vheyfhks3klm","task_subcomment","A ""read-only editor"" is the view mode… I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).","A ""read-only editor"" is the view mode… I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,21,NA,"['A ""read-only editor"" is the view mode… I\'m not really sure there\'s much value in going down the route, but instead we\'d want to combine the two edit tabs together (except for users with VisualEditor disabled).']",NA,0,"A ""read-only editor"" is the view mode… I\"
11323,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","A ""read-only editor"" is the view mode… I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).",1385386552,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-qh3lrsa2vheyfhks3klm","task_subcomment","A ""read-only editor"" is the view mode… I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).","A ""read-only editor"" is the view mode… I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,21,NA,"['A ""read-only editor"" is the view mode… I\'m not really sure there\'s much value in going down the route, but instead we\'d want to combine the two edit tabs together (except for users with VisualEditor disabled).']",NA,0,"s much value in going down the route, but instead we\"
11493,"VisualEditor: Suppression of Cite error in templates still paints a phantom","Screenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","Low",25,1392426157,NA,"resolved","True","c1",3,"False","False",1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,"VisualEditor: Suppression of Cite error in templates still paints a phantom."
11493,"VisualEditor: Suppression of Cite error in templates still paints a phantom","Screenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","Low",25,1392426157,NA,"resolved","True","c1",3,"False","False",1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,"Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template."
11493,"VisualEditor: Suppression of Cite error in templates still paints a phantom","Screenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","Low",25,1392426157,NA,"resolved","True","c1",3,"False","False",1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,"That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message."
11493,"VisualEditor: Suppression of Cite error in templates still paints a phantom","Screenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","Low",25,1392426157,NA,"resolved","True","c1",3,"False","False",1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,"See screenshot."
11493,"VisualEditor: Suppression of Cite error in templates still paints a phantom","Screenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

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

**Attached**: {F11227}","Low",25,1392426157,NA,"resolved","True","c1",3,"False","False",1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,"--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}"
11494,"VisualEditor: Suppression of Cite error in templates still paints a phantom","I believe that this has been fixed for some time; I cannot replicate now.",1392426157,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v6t7ev5julnky6rafmtd","task_subcomment","I believe that this has been fixed for some time; I cannot replicate now.","I believe that this has been fixed for some time; I cannot replicate now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,32,NA,"['I believe that this has been fixed for some time; I cannot replicate now.']",NA,1,"I believe that this has been fixed for some time; I cannot replicate now."
11568,"Messing up Math formulas","Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441

https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206

https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal",1373289300,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_description","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441

https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206

https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

URL

URL

URL

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal","Low",25,1373592757,NA,"resolved","True","c1",3,"False","False",1,NA,"['Messing up Math formulas.', 'Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.', ""URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Messing up Math formulas."
11568,"Messing up Math formulas","Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441

https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206

https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal",1373289300,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_description","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441

https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206

https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

URL

URL

URL

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal","Low",25,1373592757,NA,"resolved","True","c1",3,"False","False",1,NA,"['Messing up Math formulas.', 'Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.', ""URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all."
11568,"Messing up Math formulas","Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441

https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206

https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal",1373289300,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_description","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441

https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206

https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

URL

URL

URL

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal","Low",25,1373592757,NA,"resolved","True","c1",3,"False","False",1,NA,"['Messing up Math formulas.', 'Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.', ""URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal"
11568,"Messing up Math formulas","Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441

https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206

https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal",1373289300,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_description","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441

https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206

https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

URL

URL

URL

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal","Low",25,1373592757,NA,"resolved","True","c1",3,"False","False",1,NA,"['Messing up Math formulas.', 'Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.', ""URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing."
11569,"Messing up Math formulas","**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",1373592757,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_subcomment","**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%","**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['**cbm.wikipedia** wrote:\n\nThis is a duplicate of bug 50291.', 'It is a round tripping error in VisualEditor.', '%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%']",NA,0,"**cbm.wikipedia** wrote:\n\nThis is a duplicate of bug 50291."
11569,"Messing up Math formulas","**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",1373592757,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_subcomment","**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%","**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['**cbm.wikipedia** wrote:\n\nThis is a duplicate of bug 50291.', 'It is a round tripping error in VisualEditor.', '%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%']",NA,0,"It is a round tripping error in VisualEditor."
11569,"Messing up Math formulas","**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",1373592757,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_subcomment","**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%","**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['**cbm.wikipedia** wrote:\n\nThis is a duplicate of bug 50291.', 'It is a round tripping error in VisualEditor.', '%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%']",NA,0,"%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%"
11570,"Messing up Math formulas","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",1373290493,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_subcomment","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''''x'' to ''ex'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,"Just the way italics (used to mark variables) and superscript and subscript tags interact."
11570,"Messing up Math formulas","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",1373290493,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_subcomment","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''''x'' to ''ex'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,"Marking as low priority as no visible change."
11570,"Messing up Math formulas","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",1373290493,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_subcomment","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''''x'' to ''ex'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,"The changes don't actually change the visual output."
11570,"Messing up Math formulas","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",1373290493,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_subcomment","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''''x'' to ''ex'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,"So it might change ''e''''x'' to ''ex'' you could say the former is better semantically."
11570,"Messing up Math formulas","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",1373290493,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-tlllnzr2q3k5zu3yv6nh","task_subcomment","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''''x'' to ''ex'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically.

Marking as low priority as no visible change.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''''x'' to ''ex'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,"Other cases will split a complex superscript into two separate subscripts  ''K''''n'',''n'' into ''Kn'',''n'', visually the same but worse semantically."
11649,"VisualEditor: Transclusions editor should support parser functions and variables","Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}",1373104140,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-5tthiu6szwn225okbzla","task_description","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","Low",25,NA,NA,"open","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"VisualEditor: Transclusions editor should support parser functions and variables."
11649,"VisualEditor: Transclusions editor should support parser functions and variables","Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}",1373104140,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-5tthiu6szwn225okbzla","task_description","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","Low",25,NA,NA,"open","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc."
11649,"VisualEditor: Transclusions editor should support parser functions and variables","Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}",1373104140,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-5tthiu6szwn225okbzla","task_description","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","Low",25,NA,NA,"open","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"This makes it impossible to edit expr1 in VE."
11649,"VisualEditor: Transclusions editor should support parser functions and variables","Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}",1373104140,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-5tthiu6szwn225okbzla","task_description","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","Low",25,NA,NA,"open","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"Same for parserfunctions like urlencode and template messages."
11649,"VisualEditor: Transclusions editor should support parser functions and variables","Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}",1373104140,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-5tthiu6szwn225okbzla","task_description","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","Low",25,NA,NA,"open","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode."
11649,"VisualEditor: Transclusions editor should support parser functions and variables","Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}",1373104140,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-5tthiu6szwn225okbzla","task_description","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","Low",25,NA,NA,"open","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"Until we can, we should show an explanatory message when the user attempts to add one."
11649,"VisualEditor: Transclusions editor should support parser functions and variables","Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}",1373104140,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-5tthiu6szwn225okbzla","task_description","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}","Low",25,NA,NA,"open","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"**See also:**\n{T54607}"
11650,"VisualEditor: Transclusions editor should support parser functions and variables","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].",1587917120,"PHID-USER-wmk4bsljm5c77zhckwcj","PHID-TASK-5tthiu6szwn225okbzla","task_subcomment","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,355,NA,"['So yeah.', 'Matma Rex has merged T249860 with this task.', 'Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].']",NA,0,"So yeah."
11650,"VisualEditor: Transclusions editor should support parser functions and variables","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].",1587917120,"PHID-USER-wmk4bsljm5c77zhckwcj","PHID-TASK-5tthiu6szwn225okbzla","task_subcomment","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,355,NA,"['So yeah.', 'Matma Rex has merged T249860 with this task.', 'Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].']",NA,0,"Matma Rex has merged T249860 with this task."
11650,"VisualEditor: Transclusions editor should support parser functions and variables","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].",1587917120,"PHID-USER-wmk4bsljm5c77zhckwcj","PHID-TASK-5tthiu6szwn225okbzla","task_subcomment","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,355,NA,"['So yeah.', 'Matma Rex has merged T249860 with this task.', 'Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].']",NA,0,"Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]]."
11651,"VisualEditor: Transclusions editor should support parser functions and variables","If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?",1435260148,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-5tthiu6szwn225okbzla","task_subcomment","If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?","If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,103,NA,"[""If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g."", '{{# is never a template) or comparing it to a list of parser functions?']",NA,0,"{{# is never a template) or comparing it to a list of parser functions?"
11651,"VisualEditor: Transclusions editor should support parser functions and variables","If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?",1435260148,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-5tthiu6szwn225okbzla","task_subcomment","If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?","If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,103,NA,"[""If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g."", '{{# is never a template) or comparing it to a list of parser functions?']",NA,0,"If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g."
11652,"VisualEditor: Transclusions editor should support parser functions and variables","Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.",1373465761,"PHID-USER-o34e5i3eq4nstbvcf26w","PHID-TASK-5tthiu6szwn225okbzla","task_subcomment","Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.","Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace.', 'For example {{formatnum:...}} is probably used a lot there.']",NA,0,"Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace."
11652,"VisualEditor: Transclusions editor should support parser functions and variables","Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.",1373465761,"PHID-USER-o34e5i3eq4nstbvcf26w","PHID-TASK-5tthiu6szwn225okbzla","task_subcomment","Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.","Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace.', 'For example {{formatnum:...}} is probably used a lot there.']",NA,0,"For example {{formatnum:...}} is probably used a lot there."
11653,"VisualEditor: Transclusions editor should support parser functions and variables","Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.",1373160763,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5tthiu6szwn225okbzla","task_subcomment","Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.","Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"[""Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.""]",NA,0,"Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection."
11748,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,"PHID-USER-yek7ymogrv4qc67oilhf","PHID-TASK-wzei4tpax7kpf3oq25mp","task_description","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Low",25,1431047236,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: Link inspector should preview the linked page (à la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)."
11748,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,"PHID-USER-yek7ymogrv4qc67oilhf","PHID-TASK-wzei4tpax7kpf3oq25mp","task_description","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Low",25,1431047236,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: Link inspector should preview the linked page (à la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right."
11748,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,"PHID-USER-yek7ymogrv4qc67oilhf","PHID-TASK-wzei4tpax7kpf3oq25mp","task_description","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Low",25,1431047236,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: Link inspector should preview the linked page (à la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"You then have to follow the link (which is hard in edit mode) and go looking again."
11748,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,"PHID-USER-yek7ymogrv4qc67oilhf","PHID-TASK-wzei4tpax7kpf3oq25mp","task_description","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Low",25,1431047236,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: Link inspector should preview the linked page (à la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*."
11748,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,"PHID-USER-yek7ymogrv4qc67oilhf","PHID-TASK-wzei4tpax7kpf3oq25mp","task_description","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","Low",25,1431047236,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: Link inspector should preview the linked page (à la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL"
11749,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","This is effectively now solved with the link image/data preview",1431047236,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","This is effectively now solved with the link image/data preview","This is effectively now solved with the link image/data preview",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,96,NA,"['This is effectively now solved with the link image/data preview']",NA,0,"This is effectively now solved with the link image/data preview"
11750,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading."
11750,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?"
11750,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"Is [[AC/DC]] leading to an article about electrical engineering or about a band?"
11750,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure."
11750,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"(Although reusing the Hovercards code makes sense, too.)"
11750,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"It probably shouldn't be the highest priority, but as an editor, I would like something like this."
11750,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."
11750,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"So I would love to see something more than just the title when I'm linking."
11750,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."
11751,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.",1377023920,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.","I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"[""I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then."", ""Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.""]",NA,0,"I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then."
11751,"VisualEditor: Link inspector should preview the linked page (à la Navigation Popups)","I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.",1377023920,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wzei4tpax7kpf3oq25mp","task_subcomment","I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.","I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"[""I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then."", ""Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.""]",NA,0,"Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile."
12509,"VisualEditor: Add static name property to CE nodes","DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal",1362405720,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-qrmj2zvtj5xzsxn37rp3","task_description","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","Low",25,1362705677,NA,"resolved","True","c1",1,"True","False",-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: Add static name property to CE nodes."
12509,"VisualEditor: Add static name property to CE nodes","DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal",1362405720,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-qrmj2zvtj5xzsxn37rp3","task_description","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","Low",25,1362705677,NA,"resolved","True","c1",1,"True","False",-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"DM nodes have a static name property which is used by the nodeRegistry."
12509,"VisualEditor: Add static name property to CE nodes","DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal",1362405720,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-qrmj2zvtj5xzsxn37rp3","task_description","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","Low",25,1362705677,NA,"resolved","True","c1",1,"True","False",-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"CE nodes currently have their names written out at least twice."
12509,"VisualEditor: Add static name property to CE nodes","DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal",1362405720,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-qrmj2zvtj5xzsxn37rp3","task_description","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","Low",25,1362705677,NA,"resolved","True","c1",1,"True","False",-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal"
12509,"VisualEditor: Add static name property to CE nodes","DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal",1362405720,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-qrmj2zvtj5xzsxn37rp3","task_description","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal","Low",25,1362705677,NA,"resolved","True","c1",1,"True","False",-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."
12510,"VisualEditor: Add static name property to CE nodes","Related URL: https://gerrit.wikimedia.org/r/52545 (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7)",1362697441,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-qrmj2zvtj5xzsxn37rp3","task_subcomment","Related URL: https://gerrit.wikimedia.org/r/52545 (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7)","Related URL: GERRIT_URL (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7)",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-17,NA,"['Related URL: GERRIT_URL (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7)']",NA,0,"Related URL: GERRIT_URL (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7)"
12511,"VisualEditor: Add static name property to CE nodes","Fixed with https://gerrit.wikimedia.org/r/#/c/52545/",1362610508,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-qrmj2zvtj5xzsxn37rp3","task_subcomment","Fixed with https://gerrit.wikimedia.org/r/#/c/52545/","Fixed with URL",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-17,NA,"['Fixed with URL']",NA,0,"Fixed with URL"
12556,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars","Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359158880,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-fbrnpd67ntdl7dxrvivk","task_description","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",1,"True","False",-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars."
12556,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars","Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359158880,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-fbrnpd67ntdl7dxrvivk","task_description","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",1,"True","False",-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively."
12556,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars","Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359158880,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-fbrnpd67ntdl7dxrvivk","task_description","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",1,"True","False",-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this."
12556,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars","Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359158880,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-fbrnpd67ntdl7dxrvivk","task_description","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",1,"True","False",-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement"
12556,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars","Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359158880,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-fbrnpd67ntdl7dxrvivk","task_description","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",1,"True","False",-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."
12556,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars","Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement",1359158880,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-fbrnpd67ntdl7dxrvivk","task_description","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",1,"True","False",-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"And we're currently duplicating this internal logic at the cost of decentralisation."
13645,"Flow: SSL error on email notifications","Visit a link in an email notification for a Flow event – you'll receive an SSL error.

--------------------------
**Version**: master
**Severity**: normal",1382995560,"PHID-USER-yu5wnmvkjecufsjgh2fa","PHID-TASK-tdujfoz6otc4aeopydss","task_description","Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event – you'll receive an SSL error.

--------------------------
**Version**: master
**Severity**: normal","Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event – you'll receive an SSL error.

--------------------------
**Version**: master
**Severity**: normal","Needs Triage",90,1383175363,NA,"resolved","True","c2",3,"False","False",8,"True","['Flow: SSL error on email notifications.', ""Visit a link in an email notification for a Flow event – you'll receive an SSL error."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"Flow: SSL error on email notifications."
13645,"Flow: SSL error on email notifications","Visit a link in an email notification for a Flow event – you'll receive an SSL error.

--------------------------
**Version**: master
**Severity**: normal",1382995560,"PHID-USER-yu5wnmvkjecufsjgh2fa","PHID-TASK-tdujfoz6otc4aeopydss","task_description","Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event – you'll receive an SSL error.

--------------------------
**Version**: master
**Severity**: normal","Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event – you'll receive an SSL error.

--------------------------
**Version**: master
**Severity**: normal","Needs Triage",90,1383175363,NA,"resolved","True","c2",3,"False","False",8,"True","['Flow: SSL error on email notifications.', ""Visit a link in an email notification for a Flow event – you'll receive an SSL error."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: master\n**Severity**: normal"
13645,"Flow: SSL error on email notifications","Visit a link in an email notification for a Flow event – you'll receive an SSL error.

--------------------------
**Version**: master
**Severity**: normal",1382995560,"PHID-USER-yu5wnmvkjecufsjgh2fa","PHID-TASK-tdujfoz6otc4aeopydss","task_description","Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event – you'll receive an SSL error.

--------------------------
**Version**: master
**Severity**: normal","Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event – you'll receive an SSL error.

--------------------------
**Version**: master
**Severity**: normal","Needs Triage",90,1383175363,NA,"resolved","True","c2",3,"False","False",8,"True","['Flow: SSL error on email notifications.', ""Visit a link in an email notification for a Flow event – you'll receive an SSL error."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"Visit a link in an email notification for a Flow event – you'll receive an SSL error."
13646,"Flow: SSL error on email notifications","**bsitu** wrote:

solved by configuring the server",1383175363,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-tdujfoz6otc4aeopydss","task_subcomment","**bsitu** wrote:

solved by configuring the server","**bsitu** wrote:

solved by configuring the server",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,9,"True","['**bsitu** wrote:\n\nsolved by configuring the server']",NA,0,"**bsitu** wrote:\n\nsolved by configuring the server"
13647,"Flow: SSL error on email notifications","**bsitu** wrote:

same for the following code:

global $wgServer;
echo $wgServer;


http://ee-flow.wmflabs.org vs //ee-flow.wmflabs.org",1383160996,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-tdujfoz6otc4aeopydss","task_subcomment","**bsitu** wrote:

same for the following code:

global $wgServer;
echo $wgServer;


http://ee-flow.wmflabs.org vs //ee-flow.wmflabs.org","**bsitu** wrote:

same for the following code:

global $wgServer;
echo $wgServer;


URL vs //ee-flow.wmflabs.org",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,9,"True","['**bsitu** wrote:\n\nsame for the following code:\n\nglobal $wgServer;\necho $wgServer;\n\n\nURL vs //ee-flow.wmflabs.org']",NA,0,"**bsitu** wrote:\n\nsame for the following code:\n\nglobal $wgServer;\necho $wgServer;\n\n\nURL vs //ee-flow.wmflabs.org"
13648,"Flow: SSL error on email notifications","**bsitu** wrote:

I guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page

echo SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );",1383160738,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-tdujfoz6otc4aeopydss","task_subcomment","**bsitu** wrote:

I guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page

echo SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );","**bsitu** wrote:

I guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page

echo SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,9,"True","[""**bsitu** wrote:\n\nI guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page\n\necho SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );""]",NA,0,"**bsitu** wrote:\n\nI guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page\n\necho SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );"
13649,"Flow: SSL error on email notifications","The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/375, but people from the community are welcome to contribute here and in Gerrit.",1383032735,"PHID-USER-gbl4hfak3cfurt3c7skd","PHID-TASK-tdujfoz6otc4aeopydss","task_subcomment","The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/375, but people from the community are welcome to contribute here and in Gerrit.","The WMF core features team tracks this bug on Mingle card URL but people from the community are welcome to contribute here and in Gerrit.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,8,"True","['The WMF core features team tracks this bug on Mingle card URL but people from the community are welcome to contribute here and in Gerrit.']",NA,0,"The WMF core features team tracks this bug on Mingle card URL but people from the community are welcome to contribute here and in Gerrit."
13650,"Flow: SSL error on email notifications","What's an example link of what you're being given?",1382995963,"PHID-USER-6vzzsmi22zem6yttr6vp","PHID-TASK-tdujfoz6otc4aeopydss","task_subcomment","What's an example link of what you're being given?","What's an example link of what you're being given?",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,8,"True","[""What's an example link of what you're being given?""]",NA,0,"What's an example link of what you're being given?"
13665,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Example[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal",1382619360,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-drck3ontm2hvae6wzpnc","task_description","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone URL
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: URL
2: URL
3: URL
4: URL

--------------------------
**Version**: unspecified
**Severity**: normal","Needs Triage",90,1382619967,NA,"resolved","True","c2",3,"False","False",8,"True","['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'Workaround it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP."
13665,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Example[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal",1382619360,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-drck3ontm2hvae6wzpnc","task_description","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone URL
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: URL
2: URL
3: URL
4: URL

--------------------------
**Version**: unspecified
**Severity**: normal","Needs Triage",90,1382619967,NA,"resolved","True","c2",3,"False","False",8,"True","['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'Workaround it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Started to happen after updating Jenkins Git plugin."
13665,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Example[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal",1382619360,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-drck3ontm2hvae6wzpnc","task_description","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone URL
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: URL
2: URL
3: URL
4: URL

--------------------------
**Version**: unspecified
**Severity**: normal","Needs Triage",90,1382619967,NA,"resolved","True","c2",3,"False","False",8,"True","['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'Workaround it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Reverting the plugin to a earlier version did not help."
13665,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Example[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal",1382619360,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-drck3ontm2hvae6wzpnc","task_description","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone URL
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: URL
2: URL
3: URL
4: URL

--------------------------
**Version**: unspecified
**Severity**: normal","Needs Triage",90,1382619967,NA,"resolved","True","c2",3,"False","False",8,"True","['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'Workaround it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Workaround it so clone the repositories via SSH[2]."
13665,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Example[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal",1382619360,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-drck3ontm2hvae6wzpnc","task_description","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone URL
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: URL
2: URL
3: URL
4: URL

--------------------------
**Version**: unspecified
**Severity**: normal","Needs Triage",90,1382619967,NA,"resolved","True","c2",3,"False","False",8,"True","['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'Workaround it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Contacted Cloudbees support[3]."
13665,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Example[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal",1382619360,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-drck3ontm2hvae6wzpnc","task_description","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone URL
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: URL
2: URL
3: URL
4: URL

--------------------------
**Version**: unspecified
**Severity**: normal","Needs Triage",90,1382619967,NA,"resolved","True","c2",3,"False","False",8,"True","['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'Workaround it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"They were able to reproduce the problem[4] and fix it."
13665,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Example[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal",1382619360,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-drck3ontm2hvae6wzpnc","task_description","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone URL
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: URL
2: URL
3: URL
4: URL

--------------------------
**Version**: unspecified
**Severity**: normal","Needs Triage",90,1382619967,NA,"resolved","True","c2",3,"False","False",8,"True","['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'Workaround it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal"
13665,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Example[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal",1382619360,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-drck3ontm2hvae6wzpnc","task_description","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218

--------------------------
**Version**: unspecified
**Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]:

...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone URL
...

Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.

Workaround it so clone the repositories via SSH[2].

Contacted Cloudbees support[3].

They were able to reproduce the problem[4] and fix it.

1: URL
2: URL
3: URL
4: URL

--------------------------
**Version**: unspecified
**Severity**: normal","Needs Triage",90,1382619967,NA,"resolved","True","c2",3,"False","False",8,"True","['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'Workaround it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."
13666,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Change 91593 merged by Cmcmahon:
Clone Git repositories via anonymous HTTP

https://gerrit.wikimedia.org/r/91593",1382628110,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-drck3ontm2hvae6wzpnc","task_subcomment","Change 91593 merged by Cmcmahon:
Clone Git repositories via anonymous HTTP

https://gerrit.wikimedia.org/r/91593","Change 91593 merged by Cmcmahon:
Clone Git repositories via anonymous HTTP

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,8,"True","['Change 91593 merged by Cmcmahon:\nClone Git repositories via anonymous HTTP\n\nGERRIT_URL']",NA,0,"Change 91593 merged by Cmcmahon:\nClone Git repositories via anonymous HTTP\n\nGERRIT_URL"
13667,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP","Change 91593 had a related patch set uploaded by Zfilipin:
Clone Git repositories via anonymous HTTP

https://gerrit.wikimedia.org/r/91593",1382619640,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-drck3ontm2hvae6wzpnc","task_subcomment","Change 91593 had a related patch set uploaded by Zfilipin:
Clone Git repositories via anonymous HTTP

https://gerrit.wikimedia.org/r/91593","Change 91593 had a related patch set uploaded by Zfilipin:
Clone Git repositories via anonymous HTTP

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,8,"True","['Change 91593 had a related patch set uploaded by Zfilipin:\nClone Git repositories via anonymous HTTP\n\nGERRIT_URL']",NA,0,"Change 91593 had a related patch set uploaded by Zfilipin:\nClone Git repositories via anonymous HTTP\n\nGERRIT_URL"
13752,"Can't login to wikisource.org","Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_description","Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Needs Triage",90,1384635692,NA,"invalid","True","c2",3,"False","False",5,"True","[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language  does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"The following was outputted when I tried\nfamily = \"
13752,"Can't login to wikisource.org","Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_description","Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Needs Triage",90,1384635692,NA,"invalid","True","c2",3,"False","False",5,"True","[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language  does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"\nmylang = \"
13752,"Can't login to wikisource.org","Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_description","Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Needs Triage",90,1384635692,NA,"invalid","True","c2",3,"False","False",5,"True","[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language  does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language  does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL"
13752,"Can't login to wikisource.org","Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_description","Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Needs Triage",90,1384635692,NA,"invalid","True","c2",3,"False","False",5,"True","[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language  does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Can't login to wikisource.org."
13752,"Can't login to wikisource.org","Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_description","Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script.

The following was outputted when I tried
family = 'wikisource'
mylang = ''

Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language  does not exist in family wikisource

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Needs Triage",90,1384635692,NA,"invalid","True","c2",3,"False","False",5,"True","[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language  does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."
13753,"Can't login to wikisource.org","closed per above",1384635692,"PHID-USER-43lnvui4hacyjrc2lflj","PHID-TASK-dhh37twcrmhqe6k4pknu","task_subcomment","closed per above","closed per above",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,11,"True","['closed per above']",NA,0,"closed per above"
13754,"Can't login to wikisource.org","Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)",1380947670,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_subcomment","Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)","Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","['Suggested method works, please close or possibly add a note somewhere in the code?', ""\\(so people like me can see that they need to do '-'\\)""]",NA,0,"Suggested method works, please close or possibly add a note somewhere in the code?"
13754,"Can't login to wikisource.org","Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)",1380947670,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_subcomment","Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)","Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","['Suggested method works, please close or possibly add a note somewhere in the code?', ""\\(so people like me can see that they need to do '-'\\)""]",NA,0,"\\(so people like me can see that they need to do '-'\\)"
13755,"Can't login to wikisource.org","My mistake, I didn't see the suggested method.",1380947668,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_subcomment","My mistake, I didn't see the suggested method.","My mistake, I didn't see the suggested method.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","[""My mistake, I didn't see the suggested method.""]",NA,0,"My mistake, I didn't see the suggested method."
13756,"Can't login to wikisource.org","- **priority**: 7 --> 5",1380947666,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_subcomment","- **priority**: 7 --> 5","- **priority**: 7 --> 5",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","['- **priority**: 7 --> 5']",NA,0,"- **priority**: 7 --> 5"
13757,"Can't login to wikisource.org","Please try the suggested method before increading priority.",1380947665,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_subcomment","Please try the suggested method before increading priority.","Please try the suggested method before increading priority.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","['Please try the suggested method before increading priority.']",NA,0,"Please try the suggested method before increading priority."
13758,"Can't login to wikisource.org","- **priority**: 5 --> 7",1380947663,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_subcomment","- **priority**: 5 --> 7","- **priority**: 5 --> 7",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","['- **priority**: 5 --> 7']",NA,0,"- **priority**: 5 --> 7"
13759,"Can't login to wikisource.org","Instead of mylang='', try using mylang='-' \(and also adapting your username config as such\).",1380947661,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-dhh37twcrmhqe6k4pknu","task_subcomment","Instead of mylang='', try using mylang='-' \(and also adapting your username config as such\).","Instead of mylang='', try using mylang='-' \(and also adapting your username config as such\).",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","[""Instead of mylang='', try using mylang='-' \\(and also adapting your username config as such\\).""]",NA,0,"Instead of mylang='', try using mylang='-' \\(and also adapting your username config as such\\)."
13803,"Force HTTPS for /token if the Consumer is not using an RSA key","We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal",1379118240,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-eltc3unjgxsy26lpygu6","task_description","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Needs Triage",90,1380551043,NA,"resolved","True","c2",3,"True","False",2,"True","['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n   Since the request results in the transmission of plain text\n   credentials in the HTTP response, the server MUST require the use of\n   a transport-layer mechanism such as TLS or SSL (or a secure channel\n   with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"Force HTTPS for /token if the Consumer is not using an RSA key."
13803,"Force HTTPS for /token if the Consumer is not using an RSA key","We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal",1379118240,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-eltc3unjgxsy26lpygu6","task_description","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Needs Triage",90,1380551043,NA,"resolved","True","c2",3,"True","False",2,"True","['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n   Since the request results in the transmission of plain text\n   credentials in the HTTP response, the server MUST require the use of\n   a transport-layer mechanism such as TLS or SSL (or a secure channel\n   with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"rfc5849 - 2.3 says that:\n\n   Since the request results in the transmission of plain text\n   credentials in the HTTP response, the server MUST require the use of\n   a transport-layer mechanism such as TLS or SSL (or a secure channel\n   with equivalent protections)."
13803,"Force HTTPS for /token if the Consumer is not using an RSA key","We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal",1379118240,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-eltc3unjgxsy26lpygu6","task_description","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Needs Triage",90,1380551043,NA,"resolved","True","c2",3,"True","False",2,"True","['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n   Since the request results in the transmission of plain text\n   credentials in the HTTP response, the server MUST require the use of\n   a transport-layer mechanism such as TLS or SSL (or a secure channel\n   with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"--------------------------\n**Version**: master\n**Severity**: normal"
13803,"Force HTTPS for /token if the Consumer is not using an RSA key","We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal",1379118240,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-eltc3unjgxsy26lpygu6","task_description","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Needs Triage",90,1380551043,NA,"resolved","True","c2",3,"True","False",2,"True","['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n   Since the request results in the transmission of plain text\n   credentials in the HTTP response, the server MUST require the use of\n   a transport-layer mechanism such as TLS or SSL (or a secure channel\n   with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"We currently don't require HTTPS for the consumer to get the authorization token."
13803,"Force HTTPS for /token if the Consumer is not using an RSA key","We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal",1379118240,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-eltc3unjgxsy26lpygu6","task_description","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Needs Triage",90,1380551043,NA,"resolved","True","c2",3,"True","False",2,"True","['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n   Since the request results in the transmission of plain text\n   credentials in the HTTP response, the server MUST require the use of\n   a transport-layer mechanism such as TLS or SSL (or a secure channel\n   with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."
13803,"Force HTTPS for /token if the Consumer is not using an RSA key","We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal",1379118240,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-eltc3unjgxsy26lpygu6","task_description","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.

rfc5849 - 2.3 says that:

   Since the request results in the transmission of plain text
   credentials in the HTTP response, the server MUST require the use of
   a transport-layer mechanism such as TLS or SSL (or a secure channel
   with equivalent protections).

However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.

--------------------------
**Version**: master
**Severity**: normal","Needs Triage",90,1380551043,NA,"resolved","True","c2",3,"True","False",2,"True","['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n   Since the request results in the transmission of plain text\n   credentials in the HTTP response, the server MUST require the use of\n   a transport-layer mechanism such as TLS or SSL (or a secure channel\n   with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."
13804,"Force HTTPS for /token if the Consumer is not using an RSA key","Change 85218 merged by jenkins-bot:
Use HTTPS for Special:MWOAuth/token

https://gerrit.wikimedia.org/r/85218",1380396294,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-eltc3unjgxsy26lpygu6","task_subcomment","Change 85218 merged by jenkins-bot:
Use HTTPS for Special:MWOAuth/token

https://gerrit.wikimedia.org/r/85218","Change 85218 merged by jenkins-bot:
Use HTTPS for Special:MWOAuth/token

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,4,"True","['Change 85218 merged by jenkins-bot:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL']",NA,1,"Change 85218 merged by jenkins-bot:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL"
13805,"Force HTTPS for /token if the Consumer is not using an RSA key","Change 85218 had a related patch set uploaded by Anomie:
Use HTTPS for Special:MWOAuth/token

https://gerrit.wikimedia.org/r/85218",1379691008,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-eltc3unjgxsy26lpygu6","task_subcomment","Change 85218 had a related patch set uploaded by Anomie:
Use HTTPS for Special:MWOAuth/token

https://gerrit.wikimedia.org/r/85218","Change 85218 had a related patch set uploaded by Anomie:
Use HTTPS for Special:MWOAuth/token

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,3,"True","['Change 85218 had a related patch set uploaded by Anomie:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL']",NA,1,"Change 85218 had a related patch set uploaded by Anomie:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL"
13806,"Force HTTPS for /token if the Consumer is not using an RSA key","(In reply to comment #0)
> However, if the Consumer is using an RSA key, then the authorization token's
> secret isn't used, so the security isn't affected by not using SSL for the
> /token call.

What about the token credentials returned in the response? Those are still plain text.",1379690874,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-eltc3unjgxsy26lpygu6","task_subcomment","(In reply to comment #0)
> However, if the Consumer is using an RSA key, then the authorization token's
> secret isn't used, so the security isn't affected by not using SSL for the
> /token call.

What about the token credentials returned in the response? Those are still plain text.","(In reply to comment #0)
QUOTE
QUOTE
QUOTE

What about the token credentials returned in the response? Those are still plain text.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,3,"True","['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about the token credentials returned in the response?', 'Those are still plain text.']",NA,1,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about the token credentials returned in the response?"
13806,"Force HTTPS for /token if the Consumer is not using an RSA key","(In reply to comment #0)
> However, if the Consumer is using an RSA key, then the authorization token's
> secret isn't used, so the security isn't affected by not using SSL for the
> /token call.

What about the token credentials returned in the response? Those are still plain text.",1379690874,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-eltc3unjgxsy26lpygu6","task_subcomment","(In reply to comment #0)
> However, if the Consumer is using an RSA key, then the authorization token's
> secret isn't used, so the security isn't affected by not using SSL for the
> /token call.

What about the token credentials returned in the response? Those are still plain text.","(In reply to comment #0)
QUOTE
QUOTE
QUOTE

What about the token credentials returned in the response? Those are still plain text.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,3,"True","['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about the token credentials returned in the response?', 'Those are still plain text.']",NA,1,"Those are still plain text."
13985,"Login with the required password change doesn't log me in globally","In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal",1380793140,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-4yoprjxsxryoacxktvyk","task_description","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal","High",80,1696629317,"PHID-USER-a6p24cvyblhfzc7we7nc","resolved","True","c2",3,"False","False",5,"True","[""Login with the required password change doesn't log me in globally."", 'In the recent user data leaking issue, we forced users to change password on login.', 'After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"In the recent user data leaking issue, we forced users to change password on login."
13985,"Login with the required password change doesn't log me in globally","In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal",1380793140,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-4yoprjxsxryoacxktvyk","task_description","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal","High",80,1696629317,"PHID-USER-a6p24cvyblhfzc7we7nc","resolved","True","c2",3,"False","False",5,"True","[""Login with the required password change doesn't log me in globally."", 'In the recent user data leaking issue, we forced users to change password on login.', 'After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project."
13985,"Login with the required password change doesn't log me in globally","In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal",1380793140,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-4yoprjxsxryoacxktvyk","task_description","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal","High",80,1696629317,"PHID-USER-a6p24cvyblhfzc7we7nc","resolved","True","c2",3,"False","False",5,"True","[""Login with the required password change doesn't log me in globally."", 'In the recent user data leaking issue, we forced users to change password on login.', 'After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal"
13985,"Login with the required password change doesn't log me in globally","In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal",1380793140,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-4yoprjxsxryoacxktvyk","task_description","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.

--------------------------
**Version**: unspecified
**Severity**: normal","High",80,1696629317,"PHID-USER-a6p24cvyblhfzc7we7nc","resolved","True","c2",3,"False","False",5,"True","[""Login with the required password change doesn't log me in globally."", 'In the recent user data leaking issue, we forced users to change password on login.', 'After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Login with the required password change doesn't log me in globally."
13986,"Login with the required password change doesn't log me in globally","Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step.",1696629317,"PHID-USER-a6p24cvyblhfzc7we7nc","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step.","Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,527,"True","[""Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step.""]",NA,0,"Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step."
13987,"Login with the required password change doesn't log me in globally","@Piramidion: Please see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems and report back here. Thanks!",1544893724,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","@Piramidion: Please see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems and report back here. Thanks!","SCREEN_NAME: Please see and follow URL and report back here. Thanks!",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,276,"True","['SCREEN_NAME: Please see and follow URL and report back here.', 'Thanks!']",NA,0,"SCREEN_NAME: Please see and follow URL and report back here."
13987,"Login with the required password change doesn't log me in globally","@Piramidion: Please see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems and report back here. Thanks!",1544893724,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","@Piramidion: Please see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems and report back here. Thanks!","SCREEN_NAME: Please see and follow URL and report back here. Thanks!",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,276,"True","['SCREEN_NAME: Please see and follow URL and report back here.', 'Thanks!']",NA,0,"Thanks!"
13988,"Login with the required password change doesn't log me in globally","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,"PHID-USER-236lfjw5qszgahq5srnq","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,276,"True","['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,"A user reported this recently."
13988,"Login with the required password change doesn't log me in globally","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,"PHID-USER-236lfjw5qszgahq5srnq","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,276,"True","['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,"He also says that the system randomly logs him out on Wikipedia too."
13988,"Login with the required password change doesn't log me in globally","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,"PHID-USER-236lfjw5qszgahq5srnq","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,276,"True","['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,"Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?"
13988,"Login with the required password change doesn't log me in globally","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,"PHID-USER-236lfjw5qszgahq5srnq","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,276,"True","['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,"Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."
13988,"Login with the required password change doesn't log me in globally","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,"PHID-USER-236lfjw5qszgahq5srnq","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,276,"True","['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,"It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."
13989,"Login with the required password change doesn't log me in globally","I haven't been able to get to it yet",1400026541,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","I haven't been able to get to it yet","I haven't been able to get to it yet",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,37,"True","[""I haven't been able to get to it yet""]",NA,0,"I haven't been able to get to it yet"
13990,"Login with the required password change doesn't log me in globally","(In reply to Chris Steipp from comment #4)
> Platform has let me schedule some password work this quarter, which this
> falls under. So March-ish is a good target.

Chris: How did reality bite, and any new approx. timeframe? :)",1399878048,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","(In reply to Chris Steipp from comment #4)
> Platform has let me schedule some password work this quarter, which this
> falls under. So March-ish is a good target.

Chris: How did reality bite, and any new approx. timeframe? :)","(In reply to Chris Steipp from comment #4)
QUOTE
QUOTE

Chris: How did reality bite, and any new approx. timeframe? :)",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,36,"True","['(In reply to Chris Steipp from comment #4)\nQUOTE\nQUOTE\n\nChris: How did reality bite, and any new approx.', 'timeframe?', ':)']",NA,0,"(In reply to Chris Steipp from comment #4)\nQUOTE\nQUOTE\n\nChris: How did reality bite, and any new approx."
13990,"Login with the required password change doesn't log me in globally","(In reply to Chris Steipp from comment #4)
> Platform has let me schedule some password work this quarter, which this
> falls under. So March-ish is a good target.

Chris: How did reality bite, and any new approx. timeframe? :)",1399878048,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","(In reply to Chris Steipp from comment #4)
> Platform has let me schedule some password work this quarter, which this
> falls under. So March-ish is a good target.

Chris: How did reality bite, and any new approx. timeframe? :)","(In reply to Chris Steipp from comment #4)
QUOTE
QUOTE

Chris: How did reality bite, and any new approx. timeframe? :)",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,36,"True","['(In reply to Chris Steipp from comment #4)\nQUOTE\nQUOTE\n\nChris: How did reality bite, and any new approx.', 'timeframe?', ':)']",NA,0,"timeframe?"
13990,"Login with the required password change doesn't log me in globally","(In reply to Chris Steipp from comment #4)
> Platform has let me schedule some password work this quarter, which this
> falls under. So March-ish is a good target.

Chris: How did reality bite, and any new approx. timeframe? :)",1399878048,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","(In reply to Chris Steipp from comment #4)
> Platform has let me schedule some password work this quarter, which this
> falls under. So March-ish is a good target.

Chris: How did reality bite, and any new approx. timeframe? :)","(In reply to Chris Steipp from comment #4)
QUOTE
QUOTE

Chris: How did reality bite, and any new approx. timeframe? :)",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,36,"True","['(In reply to Chris Steipp from comment #4)\nQUOTE\nQUOTE\n\nChris: How did reality bite, and any new approx.', 'timeframe?', ':)']",NA,0,":)"
13991,"Login with the required password change doesn't log me in globally","Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.",1389291226,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.","Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,19,"True","['Platform has let me schedule some password work this quarter, which this falls under.', 'So March-ish is a good target.']",NA,0,"Platform has let me schedule some password work this quarter, which this falls under."
13991,"Login with the required password change doesn't log me in globally","Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.",1389291226,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.","Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,19,"True","['Platform has let me schedule some password work this quarter, which this falls under.', 'So March-ish is a good target.']",NA,0,"So March-ish is a good target."
13992,"Login with the required password change doesn't log me in globally","(In reply to comment #2 by csteipp)
> I'm planning to rework the patches we put in for this particular incident,
> which will do the full SUL2 handshake after the login finishes.

csteipp: Any vague timeframe (if this is still the plan)?",1389267605,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","(In reply to comment #2 by csteipp)
> I'm planning to rework the patches we put in for this particular incident,
> which will do the full SUL2 handshake after the login finishes.

csteipp: Any vague timeframe (if this is still the plan)?","(In reply to comment #2 by csteipp)
QUOTE
QUOTE

csteipp: Any vague timeframe (if this is still the plan)?",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,19,"True","['(In reply to comment #2 by csteipp)\nQUOTE\nQUOTE\n\ncsteipp: Any vague timeframe (if this is still the plan)?']",NA,0,"(In reply to comment #2 by csteipp)\nQUOTE\nQUOTE\n\ncsteipp: Any vague timeframe (if this is still the plan)?"
13993,"Login with the required password change doesn't log me in globally","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.

I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",1380820150,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.

I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.

I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,5,"True","['I saw this last night.', ""You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects."", ""I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.""]",NA,0,"I saw this last night."
13993,"Login with the required password change doesn't log me in globally","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.

I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",1380820150,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.

I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.

I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,5,"True","['I saw this last night.', ""You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects."", ""I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.""]",NA,0,"You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects."
13993,"Login with the required password change doesn't log me in globally","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.

I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",1380820150,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.

I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.

I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,5,"True","['I saw this last night.', ""You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects."", ""I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.""]",NA,0,"I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes."
13994,"Login with the required password change doesn't log me in globally","Logins using temporary password (""Reset your password"" feature) are also affected.",1380793429,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-4yoprjxsxryoacxktvyk","task_subcomment","Logins using temporary password (""Reset your password"" feature) are also affected.","Logins using temporary password (""Reset your password"" feature) are also affected.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","['Logins using temporary password (""Reset your password"" feature) are also affected.']",NA,0,"Logins using temporary password (""Reset your password"" feature) are also affected."
13995,"forceHTTPS session cookie placed even with HTTPS opt-out set","Forced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal",1380185580,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yk4yz7wimv556d7eqmvv","task_description","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","High",80,1381853735,NA,"resolved","True","c2",3,"False","False",4,"True","['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"forceHTTPS session cookie placed even with HTTPS opt-out set."
13995,"forceHTTPS session cookie placed even with HTTPS opt-out set","Forced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal",1380185580,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yk4yz7wimv556d7eqmvv","task_description","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","High",80,1381853735,NA,"resolved","True","c2",3,"False","False",4,"True","['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\"
13995,"forceHTTPS session cookie placed even with HTTPS opt-out set","Forced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal",1380185580,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yk4yz7wimv556d7eqmvv","task_description","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","High",80,1381853735,NA,"resolved","True","c2",3,"False","False",4,"True","['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,", ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI"
13995,"forceHTTPS session cookie placed even with HTTPS opt-out set","Forced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal",1380185580,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yk4yz7wimv556d7eqmvv","task_description","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","High",80,1381853735,NA,"resolved","True","c2",3,"False","False",4,"True","['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"s force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it"
13995,"forceHTTPS session cookie placed even with HTTPS opt-out set","Forced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal",1380185580,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yk4yz7wimv556d7eqmvv","task_description","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","High",80,1381853735,NA,"resolved","True","c2",3,"False","False",4,"True","['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"Why do the technical people have meddle so... and not tell us."
13995,"forceHTTPS session cookie placed even with HTTPS opt-out set","Forced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal",1380185580,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yk4yz7wimv556d7eqmvv","task_description","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","High",80,1381853735,NA,"resolved","True","c2",3,"False","False",4,"True","['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal"
13995,"forceHTTPS session cookie placed even with HTTPS opt-out set","Forced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal",1380185580,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yk4yz7wimv556d7eqmvv","task_description","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit]

Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)


Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)


I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)


I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)

--------------------------
**Version**: master
**Severity**: normal","High",80,1381853735,NA,"resolved","True","c2",3,"False","False",4,"True","['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', "
13996,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

I have managed to reproduce it and this time noticed the trigger.  Using Google Translate on a Wikipedia page.  I have filed a new bug, Bug 55887.",1382118210,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

I have managed to reproduce it and this time noticed the trigger.  Using Google Translate on a Wikipedia page.  I have filed a new bug, Bug 55887.","**salisria** wrote:

I have managed to reproduce it and this time noticed the trigger.  Using Google Translate on a Wikipedia page.  I have filed a new bug, Bug 55887.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['**salisria** wrote:\n\nI have managed to reproduce it and this time noticed the trigger.', 'Using Google Translate on a Wikipedia page.', 'I have filed a new bug, Bug 55887.']",NA,0,"**salisria** wrote:\n\nI have managed to reproduce it and this time noticed the trigger."
13996,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

I have managed to reproduce it and this time noticed the trigger.  Using Google Translate on a Wikipedia page.  I have filed a new bug, Bug 55887.",1382118210,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

I have managed to reproduce it and this time noticed the trigger.  Using Google Translate on a Wikipedia page.  I have filed a new bug, Bug 55887.","**salisria** wrote:

I have managed to reproduce it and this time noticed the trigger.  Using Google Translate on a Wikipedia page.  I have filed a new bug, Bug 55887.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['**salisria** wrote:\n\nI have managed to reproduce it and this time noticed the trigger.', 'Using Google Translate on a Wikipedia page.', 'I have filed a new bug, Bug 55887.']",NA,0,"Using Google Translate on a Wikipedia page."
13996,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

I have managed to reproduce it and this time noticed the trigger.  Using Google Translate on a Wikipedia page.  I have filed a new bug, Bug 55887.",1382118210,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

I have managed to reproduce it and this time noticed the trigger.  Using Google Translate on a Wikipedia page.  I have filed a new bug, Bug 55887.","**salisria** wrote:

I have managed to reproduce it and this time noticed the trigger.  Using Google Translate on a Wikipedia page.  I have filed a new bug, Bug 55887.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['**salisria** wrote:\n\nI have managed to reproduce it and this time noticed the trigger.', 'Using Google Translate on a Wikipedia page.', 'I have filed a new bug, Bug 55887.']",NA,0,"I have filed a new bug, Bug 55887."
13997,"forceHTTPS session cookie placed even with HTTPS opt-out set","Confirmed fixed in a Chrome private browser session with HTTPS disabled.",1381943703,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Confirmed fixed in a Chrome private browser session with HTTPS disabled.","Confirmed fixed in a Chrome private browser session with HTTPS disabled.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['Confirmed fixed in a Chrome private browser session with HTTPS disabled.']",NA,0,"Confirmed fixed in a Chrome private browser session with HTTPS disabled."
13998,"forceHTTPS session cookie placed even with HTTPS opt-out set","If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing.",1381853735,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing.","If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,6,"True","[""If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing.""]",NA,0,"If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing."
13999,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",1381705099,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['**salisria** wrote:\n\nOkay, just tried one more thing.', 'Clearing the cookies, logging out, and logging back in.', 'That worked.', 'But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.']",NA,0,"**salisria** wrote:\n\nOkay, just tried one more thing."
13999,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",1381705099,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['**salisria** wrote:\n\nOkay, just tried one more thing.', 'Clearing the cookies, logging out, and logging back in.', 'That worked.', 'But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.']",NA,0,"Clearing the cookies, logging out, and logging back in."
13999,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",1381705099,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['**salisria** wrote:\n\nOkay, just tried one more thing.', 'Clearing the cookies, logging out, and logging back in.', 'That worked.', 'But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.']",NA,0,"That worked."
13999,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",1381705099,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.","**salisria** wrote:

Okay, just tried one more thing.  Clearing the cookies, logging out, and logging back in.  That worked.  But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['**salisria** wrote:\n\nOkay, just tried one more thing.', 'Clearing the cookies, logging out, and logging back in.', 'That worked.', 'But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.']",NA,0,"But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so."
14000,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",1381703793,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['**salisria** wrote:\n\nJust realized something.', 'One of the cookies was ""wikipedia.org"".', 'If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.', 'Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?']",NA,0,"**salisria** wrote:\n\nJust realized something."
14000,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",1381703793,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['**salisria** wrote:\n\nJust realized something.', 'One of the cookies was ""wikipedia.org"".', 'If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.', 'Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?']",NA,0,"One of the cookies was ""wikipedia.org""."
14000,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",1381703793,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['**salisria** wrote:\n\nJust realized something.', 'One of the cookies was ""wikipedia.org"".', 'If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.', 'Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?']",NA,0,"If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc."
14000,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",1381703793,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?","**salisria** wrote:

Just realized something.  One of the cookies was ""wikipedia.org"".   If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.  Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['**salisria** wrote:\n\nJust realized something.', 'One of the cookies was ""wikipedia.org"".', 'If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.', 'Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?']",NA,0,"Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out  since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?"
14001,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",1381702355,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX."
14001,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",1381702355,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"Reload the page to apply your user settings."
14001,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",1381702355,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary."
14001,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",1381702355,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"I am using Firefox 24.0."
14001,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",1381702355,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."
14001,"forceHTTPS session cookie placed even with HTTPS opt-out set","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",1381702355,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.","**salisria** wrote:

I'm getting forced into using HTTPS again today, so I'm reopening this bug.  Not only that, but clearing the cookies doesn't help.  If do that, then I get the popup message:
Central login
You are centrally logged in as XXXXXXX. Reload the page to apply your user settings.

And 15 different new HTTPS cookies added:
commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.

I am using Firefox 24.0.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"Not only that, but clearing the cookies doesn't help."
14002,"forceHTTPS session cookie placed even with HTTPS opt-out set","Thanks for checking, Brad.",1381426328,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Thanks for checking, Brad.","Thanks for checking, Brad.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['Thanks for checking, Brad.']",NA,0,"Thanks for checking, Brad."
14003,"forceHTTPS session cookie placed even with HTTPS opt-out set","I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth.",1381422212,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth.","I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,6,"True","[""I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth.""]",NA,0,"I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth."
14004,"forceHTTPS session cookie placed even with HTTPS opt-out set","Is this in fact in wmf20? I don't see it in the release notes in https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf20",1381391926,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Is this in fact in wmf20? I don't see it in the release notes in https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf20","Is this in fact in wmf20? I don't see it in the release notes in URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['Is this in fact in wmf20?', ""I don't see it in the release notes in URL""]",NA,0,"Is this in fact in wmf20?"
14004,"forceHTTPS session cookie placed even with HTTPS opt-out set","Is this in fact in wmf20? I don't see it in the release notes in https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf20",1381391926,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Is this in fact in wmf20? I don't see it in the release notes in https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf20","Is this in fact in wmf20? I don't see it in the release notes in URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['Is this in fact in wmf20?', ""I don't see it in the release notes in URL""]",NA,0,"I don't see it in the release notes in URL"
14005,"forceHTTPS session cookie placed even with HTTPS opt-out set","%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%",1381072702,"PHID-USER-jfiw563ca4r5mxfkj4vx","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%","%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","['%%%*** Bug 55368 has been marked as a duplicate of this bug.', '***%%%']",NA,0,"%%%*** Bug 55368 has been marked as a duplicate of this bug."
14005,"forceHTTPS session cookie placed even with HTTPS opt-out set","%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%",1381072702,"PHID-USER-jfiw563ca4r5mxfkj4vx","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%","%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,5,"True","['%%%*** Bug 55368 has been marked as a duplicate of this bug.', '***%%%']",NA,0,"***%%%"
14006,"forceHTTPS session cookie placed even with HTTPS opt-out set","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",1380298508,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See URL for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","['Marking this fixed, since the patch is merged.', 'It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20.', 'See URL for the schedule.', 'Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).']",NA,0,"Marking this fixed, since the patch is merged."
14006,"forceHTTPS session cookie placed even with HTTPS opt-out set","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",1380298508,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See URL for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","['Marking this fixed, since the patch is merged.', 'It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20.', 'See URL for the schedule.', 'Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).']",NA,0,"It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20."
14006,"forceHTTPS session cookie placed even with HTTPS opt-out set","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",1380298508,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See URL for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","['Marking this fixed, since the patch is merged.', 'It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20.', 'See URL for the schedule.', 'Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).']",NA,0,"See URL for the schedule."
14006,"forceHTTPS session cookie placed even with HTTPS opt-out set","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",1380298508,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See URL for the schedule.

Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","['Marking this fixed, since the patch is merged.', 'It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20.', 'See URL for the schedule.', 'Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).']",NA,0,"Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday)."
14007,"forceHTTPS session cookie placed even with HTTPS opt-out set","Change 86101 merged by jenkins-bot:
Explicitly clear forceHTTPS cookie when insecure

https://gerrit.wikimedia.org/r/86101",1380233997,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Change 86101 merged by jenkins-bot:
Explicitly clear forceHTTPS cookie when insecure

https://gerrit.wikimedia.org/r/86101","Change 86101 merged by jenkins-bot:
Explicitly clear forceHTTPS cookie when insecure

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,4,"True","['Change 86101 merged by jenkins-bot:\nExplicitly clear forceHTTPS cookie when insecure\n\nGERRIT_URL']",NA,0,"Change 86101 merged by jenkins-bot:\nExplicitly clear forceHTTPS cookie when insecure\n\nGERRIT_URL"
14008,"forceHTTPS session cookie placed even with HTTPS opt-out set","Change 86101 had a related patch set uploaded by Anomie:
Explicitly clear forceHTTPS cookie when insecure

https://gerrit.wikimedia.org/r/86101",1380205862,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","Change 86101 had a related patch set uploaded by Anomie:
Explicitly clear forceHTTPS cookie when insecure

https://gerrit.wikimedia.org/r/86101","Change 86101 had a related patch set uploaded by Anomie:
Explicitly clear forceHTTPS cookie when insecure

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,4,"True","['Change 86101 had a related patch set uploaded by Anomie:\nExplicitly clear forceHTTPS cookie when insecure\n\nGERRIT_URL']",NA,0,"Change 86101 had a related patch set uploaded by Anomie:\nExplicitly clear forceHTTPS cookie when insecure\n\nGERRIT_URL"
14009,"forceHTTPS session cookie placed even with HTTPS opt-out set","I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not.

For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again...
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue",1380197962,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not.

For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again...
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue","I wonder if this is covered by anomie's URL . Or not.

For the records: URL
URL",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","[""I wonder if this is covered by anomie's URL ."", 'Or not.', 'For the records: URL\nURL']",NA,0,"Or not."
14009,"forceHTTPS session cookie placed even with HTTPS opt-out set","I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not.

For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again...
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue",1380197962,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not.

For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again...
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue","I wonder if this is covered by anomie's URL . Or not.

For the records: URL
URL",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","[""I wonder if this is covered by anomie's URL ."", 'Or not.', 'For the records: URL\nURL']",NA,0,"For the records: URL\nURL"
14009,"forceHTTPS session cookie placed even with HTTPS opt-out set","I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not.

For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again...
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue",1380197962,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-yk4yz7wimv556d7eqmvv","task_subcomment","I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not.

For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again...
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue","I wonder if this is covered by anomie's URL . Or not.

For the records: URL
URL",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","[""I wonder if this is covered by anomie's URL ."", 'Or not.', 'For the records: URL\nURL']",NA,0,"I wonder if this is covered by anomie's URL ."
14069,"Create global account on login/rename","When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-h4tu4j445kger6aygazx","task_description","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","High",80,1430851335,"PHID-USER-xvs3y6hf6yrfn6sxrk5d","declined","True","c2",3,"False","False",1,"True","['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"Create global account on login/rename."
14069,"Create global account on login/rename","When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-h4tu4j445kger6aygazx","task_description","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","High",80,1430851335,"PHID-USER-xvs3y6hf6yrfn6sxrk5d","declined","True","c2",3,"False","False",1,"True","['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically."
14069,"Create global account on login/rename","When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-h4tu4j445kger6aygazx","task_description","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","High",80,1430851335,"PHID-USER-xvs3y6hf6yrfn6sxrk5d","declined","True","c2",3,"False","False",1,"True","['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this."
14069,"Create global account on login/rename","When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-h4tu4j445kger6aygazx","task_description","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","High",80,1430851335,"PHID-USER-xvs3y6hf6yrfn6sxrk5d","declined","True","c2",3,"False","False",1,"True","['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"Should be part of a automigration (wgCentralAuthAutoMigrate)."
14069,"Create global account on login/rename","When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-h4tu4j445kger6aygazx","task_description","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.

Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL","High",80,1430851335,"PHID-USER-xvs3y6hf6yrfn6sxrk5d","declined","True","c2",3,"False","False",1,"True","['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL"
14070,"Create global account on login/rename","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",1431506795,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,89,"True","['MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?', 'Did you run into a bug with drag and drop in phabricator workboards?', 'If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching.', ':(']",NA,0,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?"
14070,"Create global account on login/rename","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",1431506795,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,89,"True","['MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?', 'Did you run into a bug with drag and drop in phabricator workboards?', 'If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching.', ':(']",NA,0,"Did you run into a bug with drag and drop in phabricator workboards?"
14070,"Create global account on login/rename","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",1431506795,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,89,"True","['MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?', 'Did you run into a bug with drag and drop in phabricator workboards?', 'If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching.', ':(']",NA,0,"If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching."
14070,"Create global account on login/rename","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",1431506795,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,89,"True","['MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?', 'Did you run into a bug with drag and drop in phabricator workboards?', 'If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching.', ':(']",NA,0,":("
14071,"Create global account on login/rename","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",1430851335,"PHID-USER-xvs3y6hf6yrfn6sxrk5d","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,87,"True","['I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user.', 'Feel free to reopen if you feel the problem still exist.', 'Thanks.']",NA,0,"I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user."
14071,"Create global account on login/rename","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",1430851335,"PHID-USER-xvs3y6hf6yrfn6sxrk5d","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,87,"True","['I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user.', 'Feel free to reopen if you feel the problem still exist.', 'Thanks.']",NA,0,"Feel free to reopen if you feel the problem still exist."
14071,"Create global account on login/rename","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",1430851335,"PHID-USER-xvs3y6hf6yrfn6sxrk5d","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,87,"True","['I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user.', 'Feel free to reopen if you feel the problem still exist.', 'Thanks.']",NA,0,"Thanks."
14072,"Create global account on login/rename","Change 102635 abandoned by Legoktm:
Autocreate global account after rename

Reason:
Not worth it at this point

https://gerrit.wikimedia.org/r/102635",1412924758,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","Change 102635 abandoned by Legoktm:
Autocreate global account after rename

Reason:
Not worth it at this point

https://gerrit.wikimedia.org/r/102635","Change 102635 abandoned by Legoktm:
Autocreate global account after rename

Reason:
Not worth it at this point

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,58,"True","['Change 102635 abandoned by Legoktm:\nAutocreate global account after rename\n\nReason:\nNot worth it at this point\n\nGERRIT_URL']",NA,0,"Change 102635 abandoned by Legoktm:\nAutocreate global account after rename\n\nReason:\nNot worth it at this point\n\nGERRIT_URL"
14073,"Create global account on login/rename","Change 102635 had a related patch set uploaded by Legoktm:
Autocreate global account after rename

https://gerrit.wikimedia.org/r/102635",1387441864,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","Change 102635 had a related patch set uploaded by Legoktm:
Autocreate global account after rename

https://gerrit.wikimedia.org/r/102635","Change 102635 had a related patch set uploaded by Legoktm:
Autocreate global account after rename

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,16,"True","['Change 102635 had a related patch set uploaded by Legoktm:\nAutocreate global account after rename\n\nGERRIT_URL']",NA,0,"Change 102635 had a related patch set uploaded by Legoktm:\nAutocreate global account after rename\n\nGERRIT_URL"
14074,"Create global account on login/rename","(In reply to comment #0)
> Maybe this can also be checked on user login, than other (or the previous
> renamed) user accounts without a conflict can also benefit from this. Should
> be
> part of a automigration (wgCentralAuthAutoMigrate).

According to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled.",1387441778,"PHID-USER-v7vgzvvcw7v2umf737ri","PHID-TASK-h4tu4j445kger6aygazx","task_subcomment","(In reply to comment #0)
> Maybe this can also be checked on user login, than other (or the previous
> renamed) user accounts without a conflict can also benefit from this. Should
> be
> part of a automigration (wgCentralAuthAutoMigrate).

According to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled.","(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE

According to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,16,"True","['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAccording to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled.']",NA,0,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAccording to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled."
14116,"No forcehttps cookies for sister projects on AutoLogin","When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal",1376968620,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-mrggh326wjh236my5dup","task_description","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal","High",80,1380298784,NA,"resolved","True","c2",2,"True","False",-2,"True","['No forcehttps cookies for sister projects on AutoLogin.', ""When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in."", 'Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"No forcehttps cookies for sister projects on AutoLogin."
14116,"No forcehttps cookies for sister projects on AutoLogin","When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal",1376968620,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-mrggh326wjh236my5dup","task_description","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal","High",80,1380298784,NA,"resolved","True","c2",2,"True","False",-2,"True","['No forcehttps cookies for sister projects on AutoLogin.', ""When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in."", 'Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie."
14116,"No forcehttps cookies for sister projects on AutoLogin","When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal",1376968620,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-mrggh326wjh236my5dup","task_description","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal","High",80,1380298784,NA,"resolved","True","c2",2,"True","False",-2,"True","['No forcehttps cookies for sister projects on AutoLogin.', ""When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in."", 'Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal"
14116,"No forcehttps cookies for sister projects on AutoLogin","When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal",1376968620,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-mrggh326wjh236my5dup","task_description","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.

Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.

--------------------------
**Version**: unspecified
**Severity**: normal","High",80,1380298784,NA,"resolved","True","c2",2,"True","False",-2,"True","['No forcehttps cookies for sister projects on AutoLogin.', ""When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in."", 'Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in."
14117,"No forcehttps cookies for sister projects on AutoLogin","Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.",1380298784,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.","Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","[""Since this seems to be fixed, and the dependent bugs too, let's close this now."", ""Feel free to reopen if I'm mistaken.""]",NA,0,"Since this seems to be fixed, and the dependent bugs too, let's close this now."
14117,"No forcehttps cookies for sister projects on AutoLogin","Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.",1380298784,"PHID-USER-uqcn2l4ng4murmyfnvyp","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.","Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","[""Since this seems to be fixed, and the dependent bugs too, let's close this now."", ""Feel free to reopen if I'm mistaken.""]",NA,0,"Feel free to reopen if I'm mistaken."
14118,"No forcehttps cookies for sister projects on AutoLogin","I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific.",1377793627,"PHID-USER-2nopae2cxuamwcbndaih","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific.","I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,0,"True","['I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific.']",NA,0,"I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific."
14119,"No forcehttps cookies for sister projects on AutoLogin","Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.",1377791228,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.","Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,0,"True","['Second half of the patch was added as a bug by Seb35.', 'Probably good to keep this as a tracking bug, and that one for the specific issue.']",NA,0,"Second half of the patch was added as a bug by Seb35."
14119,"No forcehttps cookies for sister projects on AutoLogin","Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.",1377791228,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.","Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,0,"True","['Second half of the patch was added as a bug by Seb35.', 'Probably good to keep this as a tracking bug, and that one for the specific issue.']",NA,0,"Probably good to keep this as a tracking bug, and that one for the specific issue."
14120,"No forcehttps cookies for sister projects on AutoLogin","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",1377733592,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,0,"True","['That patch only sets the cookies.', 'Still need to clean up from them on logout, which requires touching every wiki.', 'That will be a more complex patch.']",NA,0,"That patch only sets the cookies."
14120,"No forcehttps cookies for sister projects on AutoLogin","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",1377733592,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,0,"True","['That patch only sets the cookies.', 'Still need to clean up from them on logout, which requires touching every wiki.', 'That will be a more complex patch.']",NA,0,"Still need to clean up from them on logout, which requires touching every wiki."
14120,"No forcehttps cookies for sister projects on AutoLogin","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",1377733592,"PHID-USER-doeppszazlm3r7xah4il","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,0,"True","['That patch only sets the cookies.', 'Still need to clean up from them on logout, which requires touching every wiki.', 'That will be a more complex patch.']",NA,0,"That will be a more complex patch."
14121,"No forcehttps cookies for sister projects on AutoLogin","Change 81591 merged by jenkins-bot:
Set forceHTTPS cookies for Autologin wikis

https://gerrit.wikimedia.org/r/81591",1377729697,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","Change 81591 merged by jenkins-bot:
Set forceHTTPS cookies for Autologin wikis

https://gerrit.wikimedia.org/r/81591","Change 81591 merged by jenkins-bot:
Set forceHTTPS cookies for Autologin wikis

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,0,"True","['Change 81591 merged by jenkins-bot:\nSet forceHTTPS cookies for Autologin wikis\n\nGERRIT_URL']",NA,0,"Change 81591 merged by jenkins-bot:\nSet forceHTTPS cookies for Autologin wikis\n\nGERRIT_URL"
14122,"No forcehttps cookies for sister projects on AutoLogin","Change 81591 had a related patch set uploaded by CSteipp:
Set forceHTTPS cookies for Autologin wikis

https://gerrit.wikimedia.org/r/81591",1377729473,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-mrggh326wjh236my5dup","task_subcomment","Change 81591 had a related patch set uploaded by CSteipp:
Set forceHTTPS cookies for Autologin wikis

https://gerrit.wikimedia.org/r/81591","Change 81591 had a related patch set uploaded by CSteipp:
Set forceHTTPS cookies for Autologin wikis

GERRIT_URL",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,0,"True","['Change 81591 had a related patch set uploaded by CSteipp:\nSet forceHTTPS cookies for Autologin wikis\n\nGERRIT_URL']",NA,0,"Change 81591 had a related patch set uploaded by CSteipp:\nSet forceHTTPS cookies for Autologin wikis\n\nGERRIT_URL"
14191,"login broken on beta labs","As of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page

--------------------------
**Version**: unspecified
**Severity**: major",1374696600,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-wsyuomejiy425vjowzno","task_description","login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page

--------------------------
**Version**: unspecified
**Severity**: major","login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""

URL

--------------------------
**Version**: unspecified
**Severity**: major","High",80,1374759362,NA,"resolved","True","c2",1,"False","False",-5,"True","['login broken on beta labs.', 'As of 24 July, attempts to login all result in an error ""Login error\nThere was an unexpected error logging in.', 'Please try again...""\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"login broken on beta labs."
14191,"login broken on beta labs","As of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page

--------------------------
**Version**: unspecified
**Severity**: major",1374696600,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-wsyuomejiy425vjowzno","task_description","login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page

--------------------------
**Version**: unspecified
**Severity**: major","login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""

URL

--------------------------
**Version**: unspecified
**Severity**: major","High",80,1374759362,NA,"resolved","True","c2",1,"False","False",-5,"True","['login broken on beta labs.', 'As of 24 July, attempts to login all result in an error ""Login error\nThere was an unexpected error logging in.', 'Please try again...""\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"As of 24 July, attempts to login all result in an error ""Login error\nThere was an unexpected error logging in."
14191,"login broken on beta labs","As of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page

--------------------------
**Version**: unspecified
**Severity**: major",1374696600,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-wsyuomejiy425vjowzno","task_description","login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page

--------------------------
**Version**: unspecified
**Severity**: major","login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""

URL

--------------------------
**Version**: unspecified
**Severity**: major","High",80,1374759362,NA,"resolved","True","c2",1,"False","False",-5,"True","['login broken on beta labs.', 'As of 24 July, attempts to login all result in an error ""Login error\nThere was an unexpected error logging in.', 'Please try again...""\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"Please try again...""\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major"
14192,"login broken on beta labs","Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with https://gerrit.wikimedia.org/r/#/c/75842/

I managed to log in beta :]",1374759362,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with https://gerrit.wikimedia.org/r/#/c/75842/

I managed to log in beta :]","Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with URL

I managed to log in beta :]",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['Congratulations Max Semenik, cookie being stripped was the issue.', 'Fixed by Mark Bergsma with URL\n\nI managed to log in beta :]']",NA,0,"Congratulations Max Semenik, cookie being stripped was the issue."
14192,"login broken on beta labs","Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with https://gerrit.wikimedia.org/r/#/c/75842/

I managed to log in beta :]",1374759362,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with https://gerrit.wikimedia.org/r/#/c/75842/

I managed to log in beta :]","Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with URL

I managed to log in beta :]",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['Congratulations Max Semenik, cookie being stripped was the issue.', 'Fixed by Mark Bergsma with URL\n\nI managed to log in beta :]']",NA,0,"Fixed by Mark Bergsma with URL\n\nI managed to log in beta :]"
14193,"login broken on beta labs","Confirmed, $_COOKIE is empty.",1374704837,"PHID-USER-aasrweh54ew7py3agvg2","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","Confirmed, $_COOKIE is empty.","Confirmed, $_COOKIE is empty.",NA,NA,NA,NA,NA,"True","c2",1,"False",NA,-5,"True","['Confirmed, $_COOKIE is empty.']",NA,0,"Confirmed, $_COOKIE is empty."
14194,"login broken on beta labs","You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.",1374702424,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.","You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['You probably want a RT to ping mark.', 'He did some cookies related work on varnish during the afternoon.']",NA,0,"You probably want a RT to ping mark."
14194,"login broken on beta labs","You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.",1374702424,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.","You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['You probably want a RT to ping mark.', 'He did some cookies related work on varnish during the afternoon.']",NA,0,"He did some cookies related work on varnish during the afternoon."
14195,"login broken on beta labs","(In reply to comment #4)
> possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?

After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",1374701338,"PHID-USER-aasrweh54ew7py3agvg2","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","(In reply to comment #4)
> possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?

After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.","(In reply to comment #4)
QUOTE

After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",NA,NA,NA,NA,NA,"True","c2",1,"False",NA,-5,"True","['(In reply to comment #4)\nQUOTE\n\nAfter a quick test revert, turns out my CA changes are not the culprit.', 'Maybe, Varnish not letting cookies through?', 'CC Mark.']",NA,0,"(In reply to comment #4)\nQUOTE\n\nAfter a quick test revert, turns out my CA changes are not the culprit."
14195,"login broken on beta labs","(In reply to comment #4)
> possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?

After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",1374701338,"PHID-USER-aasrweh54ew7py3agvg2","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","(In reply to comment #4)
> possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?

After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.","(In reply to comment #4)
QUOTE

After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",NA,NA,NA,NA,NA,"True","c2",1,"False",NA,-5,"True","['(In reply to comment #4)\nQUOTE\n\nAfter a quick test revert, turns out my CA changes are not the culprit.', 'Maybe, Varnish not letting cookies through?', 'CC Mark.']",NA,0,"Maybe, Varnish not letting cookies through?"
14195,"login broken on beta labs","(In reply to comment #4)
> possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?

After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",1374701338,"PHID-USER-aasrweh54ew7py3agvg2","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","(In reply to comment #4)
> possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?

After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.","(In reply to comment #4)
QUOTE

After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",NA,NA,NA,NA,NA,"True","c2",1,"False",NA,-5,"True","['(In reply to comment #4)\nQUOTE\n\nAfter a quick test revert, turns out my CA changes are not the culprit.', 'Maybe, Varnish not letting cookies through?', 'CC Mark.']",NA,0,"CC Mark."
14196,"login broken on beta labs","possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?",1374699529,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?","possibly caused by URL ?",NA,NA,NA,NA,NA,"True","c2",1,"False",NA,-5,"True","['possibly caused by URL ?']",NA,0,"possibly caused by URL ?"
14197,"login broken on beta labs","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",1374698702,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
QUOTE
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n  [""class""]=>\n  string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,"I have restarted both memcached daemon on apache32 and apache33."
14197,"login broken on beta labs","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",1374698702,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
QUOTE
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n  [""class""]=>\n  string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,"Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\"
14197,"login broken on beta labs","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",1374698702,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
QUOTE
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n  [""class""]=>\n  string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,"] = $wgObjectCaches[\"
14197,"login broken on beta labs","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",1374698702,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
QUOTE
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n  [""class""]=>\n  string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,"];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n  [""class""]=>\n  string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening."
14197,"login broken on beta labs","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",1374698702,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgObjectCaches['sessions'] );
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-]

Sessions should be in memcached:

$wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl'];


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
QUOTE
array(1) {
  [""class""]=>
  string(22) ""MemcachedPeclBagOStuff""
}



Not sure what is happening.  Need to rush out to bed right now.",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n  [""class""]=>\n  string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,"Need to rush out to bed right now."
14198,"login broken on beta labs","Maybe the session are wrong in memcached ,

When login in:

tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached


enwiki-36e3721b: 0.6819   9.8M  [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-36e3721b: 0.6823   9.8M  [memcached] result: NOT FOUND
enwiki-36e3721b: 0.8519  18.2M  [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-f1d77f0c: 0.2077   6.8M  CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
enwiki-f1d77f0c: 0.2294   9.8M  MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.
enwiki-f1d77f0c: 0.2295   9.8M  [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)
enwiki-f1d77f0c: 0.2298   9.8M  [memcached] result: NOT FOUND
enwiki-f1d77f0c: 0.3549  18.2M  [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)


hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki
> get enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0
Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]
MemCached error
> get enwiki:session:556d9a1698a968752c7f7c5fb5cdd699
Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]
wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";
> 


The memcached error is weird.",1374698291,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","Maybe the session are wrong in memcached ,

When login in:

tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached


enwiki-36e3721b: 0.6819   9.8M  [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-36e3721b: 0.6823   9.8M  [memcached] result: NOT FOUND
enwiki-36e3721b: 0.8519  18.2M  [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-f1d77f0c: 0.2077   6.8M  CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
enwiki-f1d77f0c: 0.2294   9.8M  MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.
enwiki-f1d77f0c: 0.2295   9.8M  [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)
enwiki-f1d77f0c: 0.2298   9.8M  [memcached] result: NOT FOUND
enwiki-f1d77f0c: 0.3549  18.2M  [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)


hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki
> get enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0
Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]
MemCached error
> get enwiki:session:556d9a1698a968752c7f7c5fb5cdd699
Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]
wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";
> 


The memcached error is weird.","Maybe the session are wrong in memcached ,

When login in:

tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached


enwiki-36e3721b: 0.6819   9.8M  [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-36e3721b: 0.6823   9.8M  [memcached] result: NOT FOUND
enwiki-36e3721b: 0.8519  18.2M  [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-f1d77f0c: 0.2077   6.8M  CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
enwiki-f1d77f0c: 0.2294   9.8M  MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.
enwiki-f1d77f0c: 0.2295   9.8M  [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)
enwiki-f1d77f0c: 0.2298   9.8M  [memcached] result: NOT FOUND
enwiki-f1d77f0c: 0.3549  18.2M  [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)


hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki
QUOTE
Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]
MemCached error
QUOTE
Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]
wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";
QUOTE


The memcached error is weird.",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['Maybe the session are wrong in memcached ,\n\nWhen login in:\n\ntail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached\n\n\nenwiki-36e3721b: 0.6819   9.8M  [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-36e3721b: 0.6823   9.8M  [memcached] result: NOT FOUND\nenwiki-36e3721b: 0.8519  18.2M  [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-f1d77f0c: 0.2077   6.8M  CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]\nenwiki-f1d77f0c: 0.2294   9.8M  MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.', 'enwiki-f1d77f0c: 0.2295   9.8M  [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\nenwiki-f1d77f0c: 0.2298   9.8M  [memcached] result: NOT FOUND\nenwiki-f1d77f0c: 0.3549  18.2M  [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\n\n\nhashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki\nQUOTE\nGetting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]\nMemCached error\nQUOTE\nGetting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]\nwsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";\nQUOTE\n\n\nThe memcached error is weird.']",NA,0,"Maybe the session are wrong in memcached ,\n\nWhen login in:\n\ntail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached\n\n\nenwiki-36e3721b: 0.6819   9.8M  [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-36e3721b: 0.6823   9.8M  [memcached] result: NOT FOUND\nenwiki-36e3721b: 0.8519  18.2M  [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-f1d77f0c: 0.2077   6.8M  CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]\nenwiki-f1d77f0c: 0.2294   9.8M  MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded."
14198,"login broken on beta labs","Maybe the session are wrong in memcached ,

When login in:

tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached


enwiki-36e3721b: 0.6819   9.8M  [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-36e3721b: 0.6823   9.8M  [memcached] result: NOT FOUND
enwiki-36e3721b: 0.8519  18.2M  [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-f1d77f0c: 0.2077   6.8M  CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
enwiki-f1d77f0c: 0.2294   9.8M  MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.
enwiki-f1d77f0c: 0.2295   9.8M  [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)
enwiki-f1d77f0c: 0.2298   9.8M  [memcached] result: NOT FOUND
enwiki-f1d77f0c: 0.3549  18.2M  [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)


hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki
> get enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0
Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]
MemCached error
> get enwiki:session:556d9a1698a968752c7f7c5fb5cdd699
Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]
wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";
> 


The memcached error is weird.",1374698291,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","Maybe the session are wrong in memcached ,

When login in:

tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached


enwiki-36e3721b: 0.6819   9.8M  [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-36e3721b: 0.6823   9.8M  [memcached] result: NOT FOUND
enwiki-36e3721b: 0.8519  18.2M  [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-f1d77f0c: 0.2077   6.8M  CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
enwiki-f1d77f0c: 0.2294   9.8M  MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.
enwiki-f1d77f0c: 0.2295   9.8M  [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)
enwiki-f1d77f0c: 0.2298   9.8M  [memcached] result: NOT FOUND
enwiki-f1d77f0c: 0.3549  18.2M  [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)


hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki
> get enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0
Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]
MemCached error
> get enwiki:session:556d9a1698a968752c7f7c5fb5cdd699
Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]
wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";
> 


The memcached error is weird.","Maybe the session are wrong in memcached ,

When login in:

tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached


enwiki-36e3721b: 0.6819   9.8M  [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-36e3721b: 0.6823   9.8M  [memcached] result: NOT FOUND
enwiki-36e3721b: 0.8519  18.2M  [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)
enwiki-f1d77f0c: 0.2077   6.8M  CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
enwiki-f1d77f0c: 0.2294   9.8M  MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.
enwiki-f1d77f0c: 0.2295   9.8M  [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)
enwiki-f1d77f0c: 0.2298   9.8M  [memcached] result: NOT FOUND
enwiki-f1d77f0c: 0.3549  18.2M  [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)


hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki
QUOTE
Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]
MemCached error
QUOTE
Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]
wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";
QUOTE


The memcached error is weird.",NA,NA,NA,NA,NA,"True","c2",1,"True",NA,-5,"True","['Maybe the session are wrong in memcached ,\n\nWhen login in:\n\ntail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached\n\n\nenwiki-36e3721b: 0.6819   9.8M  [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-36e3721b: 0.6823   9.8M  [memcached] result: NOT FOUND\nenwiki-36e3721b: 0.8519  18.2M  [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-f1d77f0c: 0.2077   6.8M  CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]\nenwiki-f1d77f0c: 0.2294   9.8M  MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.', 'enwiki-f1d77f0c: 0.2295   9.8M  [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\nenwiki-f1d77f0c: 0.2298   9.8M  [memcached] result: NOT FOUND\nenwiki-f1d77f0c: 0.3549  18.2M  [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\n\n\nhashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki\nQUOTE\nGetting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]\nMemCached error\nQUOTE\nGetting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]\nwsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";\nQUOTE\n\n\nThe memcached error is weird.']",NA,0,"enwiki-f1d77f0c: 0.2295   9.8M  [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\nenwiki-f1d77f0c: 0.2298   9.8M  [memcached] result: NOT FOUND\nenwiki-f1d77f0c: 0.3549  18.2M  [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\n\n\nhashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki\nQUOTE\nGetting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]\nMemCached error\nQUOTE\nGetting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]\nwsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";\nQUOTE\n\n\nThe memcached error is weird."
14199,"login broken on beta labs","Adding last two authors in https://git.wikimedia.org/log/mediawiki%2Fextensions%2FCentralAuth/HEAD

Aaron/Ori: Think either of your changes caused this on beta?",1374696892,"PHID-USER-z3l4i7dl52qicxtephy5","PHID-TASK-wsyuomejiy425vjowzno","task_subcomment","Adding last two authors in https://git.wikimedia.org/log/mediawiki%2Fextensions%2FCentralAuth/HEAD

Aaron/Ori: Think either of your changes caused this on beta?","Adding last two authors in URL

Aaron/Ori: Think either of your changes caused this on beta?",NA,NA,NA,NA,NA,"True","c2",1,"False",NA,-5,"True","['Adding last two authors in URL\n\nAaron/Ori: Think either of your changes caused this on beta?']",NA,0,"Adding last two authors in URL\n\nAaron/Ori: Think either of your changes caused this on beta?"
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1."
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"Log in on any wiki on orain.org (e.g."
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"meta.orain.org)."
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"2."
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"Go to any page on a non-orain.org wiki (e.g."
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"wikiconstituciocatalana.cat)."
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki."
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}"
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"Sessions don't work on non-loginwiki domains."
14273,"Sessions don't work on non-loginwiki domains","**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}",1382392320,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_description","Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu`

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE

**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki

Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).

I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.

Here is the original GitHub issue: URL
Here is our configuration (WIP): URL
We're running CentralAuth 1.22wmf22 (3756064).

--------------------------
**Version**: master
**Severity**: major

**Attached**: {F12201}","Medium",50,1382563800,NA,"invalid","True","c2",3,"False","False",7,"True","[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."
14274,"Sessions don't work on non-loginwiki domains","So after a fair amount of detective work..
A CA token needs to be set for each domain on login (as with the wikimedia sites.)

Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5
(later altered to be a more dynamic fix for the future)

Previous to this a login on espiral would create a CA token for the orain.org domain.
espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",1382563800,"PHID-USER-u7w6n5ecde66oujx33pe","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","So after a fair amount of detective work..
A CA token needs to be set for each domain on login (as with the wikimedia sites.)

Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5
(later altered to be a more dynamic fix for the future)

Previous to this a login on espiral would create a CA token for the orain.org domain.
espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.","So after a fair amount of detective work..
A CA token needs to be set for each domain on login (as with the wikimedia sites.)

Hence this fixed our problems URL
(later altered to be a more dynamic fix for the future)

Previous to this a login on espiral would create a CA token for the orain.org domain.
espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,8,"True","['So after a fair amount of detective work..\nA CA token needs to be set for each domain on login (as with the wikimedia sites.)', 'Hence this fixed our problems URL\n(later altered to be a more dynamic fix for the future)\n\nPrevious to this a login on espiral would create a CA token for the orain.org domain.', 'espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.']",NA,0,"So after a fair amount of detective work..\nA CA token needs to be set for each domain on login (as with the wikimedia sites.)"
14274,"Sessions don't work on non-loginwiki domains","So after a fair amount of detective work..
A CA token needs to be set for each domain on login (as with the wikimedia sites.)

Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5
(later altered to be a more dynamic fix for the future)

Previous to this a login on espiral would create a CA token for the orain.org domain.
espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",1382563800,"PHID-USER-u7w6n5ecde66oujx33pe","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","So after a fair amount of detective work..
A CA token needs to be set for each domain on login (as with the wikimedia sites.)

Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5
(later altered to be a more dynamic fix for the future)

Previous to this a login on espiral would create a CA token for the orain.org domain.
espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.","So after a fair amount of detective work..
A CA token needs to be set for each domain on login (as with the wikimedia sites.)

Hence this fixed our problems URL
(later altered to be a more dynamic fix for the future)

Previous to this a login on espiral would create a CA token for the orain.org domain.
espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,8,"True","['So after a fair amount of detective work..\nA CA token needs to be set for each domain on login (as with the wikimedia sites.)', 'Hence this fixed our problems URL\n(later altered to be a more dynamic fix for the future)\n\nPrevious to this a login on espiral would create a CA token for the orain.org domain.', 'espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.']",NA,0,"Hence this fixed our problems URL\n(later altered to be a more dynamic fix for the future)\n\nPrevious to this a login on espiral would create a CA token for the orain.org domain."
14274,"Sessions don't work on non-loginwiki domains","So after a fair amount of detective work..
A CA token needs to be set for each domain on login (as with the wikimedia sites.)

Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5
(later altered to be a more dynamic fix for the future)

Previous to this a login on espiral would create a CA token for the orain.org domain.
espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",1382563800,"PHID-USER-u7w6n5ecde66oujx33pe","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","So after a fair amount of detective work..
A CA token needs to be set for each domain on login (as with the wikimedia sites.)

Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5
(later altered to be a more dynamic fix for the future)

Previous to this a login on espiral would create a CA token for the orain.org domain.
espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.","So after a fair amount of detective work..
A CA token needs to be set for each domain on login (as with the wikimedia sites.)

Hence this fixed our problems URL
(later altered to be a more dynamic fix for the future)

Previous to this a login on espiral would create a CA token for the orain.org domain.
espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,8,"True","['So after a fair amount of detective work..\nA CA token needs to be set for each domain on login (as with the wikimedia sites.)', 'Hence this fixed our problems URL\n(later altered to be a more dynamic fix for the future)\n\nPrevious to this a login on espiral would create a CA token for the orain.org domain.', 'espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.']",NA,0,"espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral."
14275,"Sessions don't work on non-loginwiki domains","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to URL - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"URL is also hosted in Orain."
14275,"Sessions don't work on non-loginwiki domains","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to URL - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again."
14275,"Sessions don't work on non-loginwiki domains","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to URL - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"My session does stick, even after reboots or changing from a laptop to another."
14275,"Sessions don't work on non-loginwiki domains","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to URL - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"But then I have the same problems than the rest when logging to URL - which is double weird."
14275,"Sessions don't work on non-loginwiki domains","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to URL - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki."
14275,"Sessions don't work on non-loginwiki domains","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to URL - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"However, other Spiral users registered before the move are also finding login problems..."
14275,"Sessions don't work on non-loginwiki domains","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to URL - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"The session won't stick."
14275,"Sessions don't work on non-loginwiki domains","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to URL - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"What is weird is that I'm visiting and editing espiral.org as an identified user regularly."
14275,"Sessions don't work on non-loginwiki domains","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick.

What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another.

But then I have the same problems than the rest when logging to URL - which is double weird.

fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstitució was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"fwiw I'm admin in both wikis."
14276,"Sessions don't work on non-loginwiki domains","**kudu** wrote:

Log showing expected behavior on an *.orain.org wiki

**Attached**: {F12203}",1382392452,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-dgjqstpb5ozhxe7ypkp7","task_subcomment","**kudu** wrote:

Log showing expected behavior on an *.orain.org wiki

**Attached**: {F12203}","**kudu** wrote:

Log showing expected behavior on an *.orain.org wiki

**Attached**: {F12203}",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,7,"True","['**kudu** wrote:\n\nLog showing expected behavior on an *.orain.org wiki\n\n**Attached**: {F12203}']",NA,0,"**kudu** wrote:\n\nLog showing expected behavior on an *.orain.org wiki\n\n**Attached**: {F12203}"
14314,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal",1379948580,"PHID-USER-2trxtywh5ma4onasf4kq","PHID-TASK-zre4dw2by7umnxgdzcwg","task_description","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Medium",50,1389207325,NA,"invalid","True","c2",3,"False","False",3,"True","['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)."
14314,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal",1379948580,"PHID-USER-2trxtywh5ma4onasf4kq","PHID-TASK-zre4dw2by7umnxgdzcwg","task_description","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Medium",50,1389207325,NA,"invalid","True","c2",3,"False","False",3,"True","['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result."
14314,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal",1379948580,"PHID-USER-2trxtywh5ma4onasf4kq","PHID-TASK-zre4dw2by7umnxgdzcwg","task_description","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Medium",50,1389207325,NA,"invalid","True","c2",3,"False","False",3,"True","['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"When not having the extension active, the result is made to api.flickr.com and works as expected."
14314,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal",1379948580,"PHID-USER-2trxtywh5ma4onasf4kq","PHID-TASK-zre4dw2by7umnxgdzcwg","task_description","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Medium",50,1389207325,NA,"invalid","True","c2",3,"False","False",3,"True","['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"--------------------------\n**Version**: unspecified\n**Severity**: normal"
14314,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal",1379948580,"PHID-USER-2trxtywh5ma4onasf4kq","PHID-TASK-zre4dw2by7umnxgdzcwg","task_description","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.

When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.

--------------------------
**Version**: unspecified
**Severity**: normal","Medium",50,1389207325,NA,"invalid","True","c2",3,"False","False",3,"True","['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere  active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."
14315,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.",1389059684,"PHID-USER-a6p24cvyblhfzc7we7nc","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.","Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,18,"True","[""Can't reproduce this."", 'It seems Flickr changed how they handle HTTPS and there is no redirect now.']",NA,1,"It seems Flickr changed how they handle HTTPS and there is no redirect now."
14315,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.",1389059684,"PHID-USER-a6p24cvyblhfzc7we7nc","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.","Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,18,"True","[""Can't reproduce this."", 'It seems Flickr changed how they handle HTTPS and there is no redirect now.']",NA,1,"Can't reproduce this."
14316,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.",1384972951,"PHID-USER-ll6tmaogat2b5q7tnqas","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,12,"True","['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,"I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin."
14316,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.",1384972951,"PHID-USER-ll6tmaogat2b5q7tnqas","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,12,"True","['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,"URL redirects to URL which causes the XHR request to hang/fail."
14316,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.",1384972951,"PHID-USER-ll6tmaogat2b5q7tnqas","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,12,"True","['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,"This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"
14316,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.",1384972951,"PHID-USER-ll6tmaogat2b5q7tnqas","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.","I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,12,"True","['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,"to ''URL making the request SSL/TLS protected for all users."
14317,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","The bug that we decided this duplicated seemed similar at the time, but it is actually very different.",1381880122,"PHID-USER-ll6tmaogat2b5q7tnqas","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","The bug that we decided this duplicated seemed similar at the time, but it is actually very different.","The bug that we decided this duplicated seemed similar at the time, but it is actually very different.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,6,"True","['The bug that we decided this duplicated seemed similar at the time, but it is actually very different.']",NA,1,"The bug that we decided this duplicated seemed similar at the time, but it is actually very different."
14318,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","

*** This bug has been marked as a duplicate of bug 42468 ***",1381426891,"PHID-USER-edlps6xg553cjlnvd4ao","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","

*** This bug has been marked as a duplicate of bug 42468 ***","

*** This bug has been marked as a duplicate of bug 42468 ***",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,6,"True","['\n\n*** This bug has been marked as a duplicate of bug 42468 ***']",NA,1,"\n\n*** This bug has been marked as a duplicate of bug 42468 ***"
14319,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","(In reply to comment #1)
> A related improvement would be to use the secure API endpoint when the user
> is using https on the mediawiki site.

Only if it works. ;-)",1379997214,"PHID-USER-hyfm4swq76s4j642w46x","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","(In reply to comment #1)
> A related improvement would be to use the secure API endpoint when the user
> is using https on the mediawiki site.

Only if it works. ;-)","(In reply to comment #1)
QUOTE
QUOTE

Only if it works. ;-)",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,3,"True","['(In reply to comment #1)\nQUOTE\nQUOTE\n\nOnly if it works.', ';-)']",NA,1,"(In reply to comment #1)\nQUOTE\nQUOTE\n\nOnly if it works."
14319,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","(In reply to comment #1)
> A related improvement would be to use the secure API endpoint when the user
> is using https on the mediawiki site.

Only if it works. ;-)",1379997214,"PHID-USER-hyfm4swq76s4j642w46x","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","(In reply to comment #1)
> A related improvement would be to use the secure API endpoint when the user
> is using https on the mediawiki site.

Only if it works. ;-)","(In reply to comment #1)
QUOTE
QUOTE

Only if it works. ;-)",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,3,"True","['(In reply to comment #1)\nQUOTE\nQUOTE\n\nOnly if it works.', ';-)']",NA,1,";-)"
14320,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)","A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.",1379948656,"PHID-USER-2trxtywh5ma4onasf4kq","PHID-TASK-zre4dw2by7umnxgdzcwg","task_subcomment","A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.","A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.",NA,NA,NA,NA,NA,"True","c2",3,"False",NA,3,"True","['A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.']",NA,1,"A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site."
14665,"ULS loads many webfonts needlessly on page load","I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-u2gugtsvvbac5ylrii64","task_description","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1379659385,NA,"resolved","True","c2",1,"False","False",-8,"True","['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"ULS loads many webfonts needlessly on page load."
14665,"ULS loads many webfonts needlessly on page load","I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-u2gugtsvvbac5ylrii64","task_description","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1379659385,NA,"resolved","True","c2",1,"False","False",-8,"True","['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left."
14665,"ULS loads many webfonts needlessly on page load","I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-u2gugtsvvbac5ylrii64","task_description","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1379659385,NA,"resolved","True","c2",1,"False","False",-8,"True","['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Those are language versions of Wikipedia I hardly ever visit."
14665,"ULS loads many webfonts needlessly on page load","I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-u2gugtsvvbac5ylrii64","task_description","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1379659385,NA,"resolved","True","c2",1,"False","False",-8,"True","['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Therefore the webfonts are not used anywhere else and downloading them is quite pointless."
14665,"ULS loads many webfonts needlessly on page load","I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-u2gugtsvvbac5ylrii64","task_description","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1379659385,NA,"resolved","True","c2",1,"False","False",-8,"True","['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Therefore I strongly suggest to *not* download webfonts only for the languages list."
14665,"ULS loads many webfonts needlessly on page load","I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-u2gugtsvvbac5ylrii64","task_description","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1379659385,NA,"resolved","True","c2",1,"False","False",-8,"True","['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"This is pointless and only adds a huge overhead for no gain at all."
14665,"ULS loads many webfonts needlessly on page load","I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-u2gugtsvvbac5ylrii64","task_description","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1379659385,NA,"resolved","True","c2",1,"False","False",-8,"True","['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\"
14665,"ULS loads many webfonts needlessly on page load","I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-u2gugtsvvbac5ylrii64","task_description","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1379659385,NA,"resolved","True","c2",1,"False","False",-8,"True","['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."
14665,"ULS loads many webfonts needlessly on page load","I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-u2gugtsvvbac5ylrii64","task_description","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).

I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.

Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.

Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).

The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL","Medium",50,1379659385,NA,"resolved","True","c2",1,"False","False",-8,"True","['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."
14666,"ULS loads many webfonts needlessly on page load","(In reply to comment #13)
> I'm told this was partially fixed.
> 
> (In reply to comment #9)
> > I see few options:
> > 1) do nothing
> > 2) exclude those elements from webfonts (there is similar system as for input
> > methods)
> > 3) produce a special small font that contains all the glyphs needed to
> > display
> > all the native language names
> 
> (2) was done, as far as I understand.

I found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»",1380200110,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-u2gugtsvvbac5ylrii64","task_subcomment","(In reply to comment #13)
> I'm told this was partially fixed.
> 
> (In reply to comment #9)
> > I see few options:
> > 1) do nothing
> > 2) exclude those elements from webfonts (there is similar system as for input
> > methods)
> > 3) produce a special small font that contains all the glyphs needed to
> > display
> > all the native language names
> 
> (2) was done, as far as I understand.

I found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»","(In reply to comment #13)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

I found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","['(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area.', 'This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»']",NA,0,"(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area."
14666,"ULS loads many webfonts needlessly on page load","(In reply to comment #13)
> I'm told this was partially fixed.
> 
> (In reply to comment #9)
> > I see few options:
> > 1) do nothing
> > 2) exclude those elements from webfonts (there is similar system as for input
> > methods)
> > 3) produce a special small font that contains all the glyphs needed to
> > display
> > all the native language names
> 
> (2) was done, as far as I understand.

I found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»",1380200110,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-u2gugtsvvbac5ylrii64","task_subcomment","(In reply to comment #13)
> I'm told this was partially fixed.
> 
> (In reply to comment #9)
> > I see few options:
> > 1) do nothing
> > 2) exclude those elements from webfonts (there is similar system as for input
> > methods)
> > 3) produce a special small font that contains all the glyphs needed to
> > display
> > all the native language names
> 
> (2) was done, as far as I understand.

I found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»","(In reply to comment #13)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

I found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,4,"True","['(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area.', 'This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»']",NA,0,"This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»"
14667,"ULS loads many webfonts needlessly on page load","Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.",1379659385,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-u2gugtsvvbac5ylrii64","task_subcomment","Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.","Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.",NA,NA,NA,NA,NA,"True","c2",3,"True",NA,3,"True","['Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.']",NA,0,"Oh, and (3) is tracked at bug 40874 so we can close this AFAICS."
14668,"ULS loads many webfonts needlessly on page load","I'm told this was partially fixed.

(In reply to comment #9)
> I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.",1379659255,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-u2gugtsvvbac5ylrii64","task_subcomment","I'm told this was partially fixed.

(In reply to comment #9)
> I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.","I'm told this was partially fixed.

(In reply to comment #9)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

(2) was done, as far as I understand.
 I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.",1379659255,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-u2gugtsvvbac5ylrii64","task_subcomment","I'm told this was partially fixed.

(In reply to comment #9)
> I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.","I'm told this was partially fixed.

(In reply to comment #9)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

(2) was done, as far as I understand.
 I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.",1379659255,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-u2gugtsvvbac5ylrii64","task_subcomment","I'm told this was partially fixed.

(In reply to comment #9)
> I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.","I'm told this was partially fixed.

(In reply to comment #9)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

(2) was done, as far as I understand.
 I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.",1379659255,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-u2gugtsvvbac5ylrii64","task_subcomment","I'm told this was partially fixed.

(In reply to comment #9)
> I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.","I'm told this was partially fixed.

(In reply to comment #9)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

(2) was done, as far as I understand.
 I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.",1379659255,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-u2gugtsvvbac5ylrii64","task_subcomment","I'm told this was partially fixed.

(In reply to comment #9)
> I see few options:
> 1) do nothing
> 2) exclude those elements from webfonts (there is similar system as for input
> methods)
> 3) produce a special small font that contains all the glyphs needed to
> display
> all the native language names

(2) was done, as far as I understand.
 is the effect of  i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.","I'm told this was partially fixed.

(In reply to comment #9)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

(2) was done, as far as I understand.